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:* behave@ietf.org
> *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
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave