Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 08 Mar 2012 07:45:25 +0100

Hi Murari,

I see what you mean now (and my previous answer was wrong, so please 
disregard it)

Yes it makes sense.

Do you have any hint that this will be a common case i.e. receiving a 
RST as reply to a FIN?

If it is not expected to be common, i guess the normal thing will be to 
receive a FIN on the other direction right away, so it may not worth the 
trouble.

Regards, marcelo

El 08/03/12 07:34, Murari Sridharan escribió:
> Marcelo,
> There is discussion about how to handle RST in ESTAB state by bouncing 
> off of TRANS essentially. Why cant the same thing apply to one of the 
> FIN RCV state? Meaning if there is a RST, again all the caveats below 
> apply, but bounce of TRANS see if the RST is accepted and further data 
> flows and either move to CLOSED or come back to the FIN RCV states?
> Thanks
> Sent from my Windows 8 PC <http://windows.microsoft.com/consumer-preview>
> *From:* marcelo bagnulo braun
> *Sent:* Wednesday, March 07, 2012 10:27:13 PM
> *To:* Dmitry Anipko
> *CC:* [email-masked], Murari Sridharan
> *Subject:* Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN 
> RCV state
> Hi Dimitry,
>
> We had a long discussion about how to handle RST packets and the
> possibility of using an RST packet in a mailicious way was a concern,
> also considering that the nat64 is unable to determine how the host
> would handle the RST packet.
> Because of this, we decided to go the conservative way and don't change
> the nat64 state upon the reception of a RST packet.
>
> We also had a long discussion that there may be some more fine grained
> ways to deal with this depending whether it comes from the internal side
> or the external side.
>
> The particular case you discuss i don't think we explicilty discussed
> it, but i guess it falls in the aforementioned case of higher
> granularity and my take is the same as above. It could be a reaosnable
> optimization, but it woudl increase the complexity of the implementation.
>
> I hope this makes sense.
>
> Regards, marcelo
>
>
>
> El 08/03/12 01:06, Dmitry Anipko escribió:
> >
> > I’ve not seen any responses, comments would be appreciated.
> >
> > *From:*Dmitry Anipko
> > *Sent:* Thursday, February 23, 2012 4:21 PM
> > *To:* [email-masked]
> > *Subject:* NAT64: clarification on RST handling in V6 FIN RCV state
> >
> > Hello,
> >
> > RFC 6146, section 3.5.2.2, says that in V6 FIN RCV state **any**
> > packet other than V4 FIN must set the session lifetime to no less than
> > TCP_EST=2hours.
> >
> > If the V4 target sent RST in response to the translated V6 FIN, what
> > is the reason to keep the NAT mapping alive for TCP_EST instead of
> > TCP_TRANS?
> >
> > Should the language “if a V4 FIN packet is received,… lifetime is set
> > to TCP_TRANS” be changed to “if a V4 FIN or V4 RST packet is
> > received,… lifetime is set to TCP_TRANS”?
> >
> > -Dmitry
> >
> >
> >
> > _______________________________________________
> > Behave mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Murari Sridharan <[email-masked]>
Date: Thu, 8 Mar 2012 06:47:13 +0000

It is very dependent on higher layer behavior, but we do see cases where the close isn't graceful and we see a RST in response to a FIN. 

Thanks

________________________________________
From: marcelo bagnulo braun [[email-masked]]
Sent: Wednesday, March 07, 2012 10:45 PM
To: Murari Sridharan
Cc: Dmitry Anipko; [email-masked]
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state

Hi Murari,

Yes it makes sense.

Regards, marcelo

---

From: Murari Sridharan <[email-masked]>
Date: Thu, 8 Mar 2012 06:34:14 +0000

Marcelo,

There is discussion about how to handle RST in ESTAB state by bouncing off of TRANS essentially. Why cant the same thing apply to one of the FIN RCV state? Meaning if there is a RST, again all the caveats below apply, but bounce of TRANS see if the RST is accepted and further data flows and either move to CLOSED or come back to the FIN RCV states?

Thanks

Sent from my Windows 8 PC<http://windows.microsoft.com/consumer-preview>

From: marcelo bagnulo braun
Sent: Wednesday, March 07, 2012 10:27:13 PM
To: Dmitry Anipko
CC: [email-masked], Murari Sridharan
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state

Hi Dimitry,

I hope this makes sense.

Regards, marcelo

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Mar 2012 19:47:44 +0900

On Mar 8, 2012, at 3:45 PM, marcelo bagnulo braun wrote:

> Do you have any hint that this will be a common case i.e. receiving a RST as reply to a FIN?

I see them in traces. Yes, they happen. It's not what RFC 793 says, but it is often reality.

Last week, for example, I was trying to show a colleague what a long TCP trace looked like. I opened tcpdump and uploaded a picture to picasa. While that was happening, who knows what else my system was doing. In the tcpdump, I found 127 separate TCP sessions. Take a look at the trailing packets in the attached.

I didn't find a FIN (F without Ack) in any of the examples. I can send you the trace if you're interested.

---

From: Wesley Eddy <[email-masked]>
Date: Fri, 09 Mar 2012 01:08:28 -0500

On 3/8/2012 5:47 AM, Fred Baker wrote:
> I didn't find a FIN (F without Ack) in any of the examples.

Since FIN is set on packets coming from a synchronized state,
I'm not sure why you would expect to find a bare one without
ACK set as well?  It should fail validity tests on reception
and be ignored if ACK isn't set.  Any stack generating those
would be broken, I believe.

-- 
Wes Eddy
MTI Systems

---

From: Fred Baker <[email-masked]>
Date: Fri, 9 Mar 2012 15:44:31 +0900

On Mar 9, 2012, at 3:08 PM, Wesley Eddy wrote:

> ACK set as well?  

You missed it. The sequence is FIN, FIN-ACK, ACK. 

http://tools.ietf.org/html/rfc793, and look at the transitions 
	SYN RCVD -> FIN-WAIT-1
	ESTAB    -> FIN-WAIT-1
        ESTAB    -> CLOSE WAIT

What's there is FIN-ACK, RST. No FIN. I could understand FIN, FIN-ACK, RST (the guy sends FIN and closes the socket instantly), whether or not I agree with it. No FIN - I'm trying to figure out why there was a FIN-ACK.

> It should fail validity tests on reception

---

From: Wesley Eddy <[email-masked]>
Date: Sat, 10 Mar 2012 00:12:57 -0500

> What's there is FIN-ACK, RST. No FIN. I could understand FIN, FIN-ACK, RST (the guy sends FIN and closes the socket instantly), whether or not I agree with it. No FIN - I'm trying to figure out why…

When you say "FIN-ACK", I think you're confusing a packet
having those two bits set with a packet that ACKs the FIN
psuedobyte.  All FINs should have the ACK bit set; a bare
FIN would be bogus.

Just looking at one of the trace files you sent
("10.71.5.180.60357.txt"), the beginning of the connection
closure process begins at the line with the timestamp of
06:35:47.021523, which I assume is a TLS closure alert.
That's followed by the TCP FIN at subsecond 021552.  I'm
not sure why you say there is no FIN.  Of course the ACK
bit is set ... the connection is in a synchronized state
and it has to be set for the segment to be accepted.

At this point, I think your machine tosses the connection
state.

When mail.ietf.org sends back its own TLS closure alert
and TCP FIN, logged at subseconds 088808 and 088813.
Those generate RSTs, since you've already released the
connection.  Before the server sees those, it also
ACKs your TLS closure alert (subsecond 139113) and then it
gives you the FIN's ACK (subsecond 140386), both of which
also generate RSTs.

So, I'm not sure what you find unusual here.  It looks
fairly normal to me.

-- 
Wes Eddy
MTI Systems

---

From: Fred Baker <[email-masked]>
Date: Sat, 10 Mar 2012 09:20:46 -0800

> So, I'm not sure what you find unusual here.  It looks

well, I guess I need to re-read the spec. But the presence of a RST is what Marcelo was asking about.