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

Murari Sridharan <muraris@microsoft.com> Thu, 08 March 2012 06:34 UTC

Return-Path: <muraris@microsoft.com>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A95E21F869E for <behave@ietfa.amsl.com>; Wed, 7 Mar 2012 22:34:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level:
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y32i3am64j5x for <behave@ietfa.amsl.com>; Wed, 7 Mar 2012 22:34:21 -0800 (PST)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5D21F869A for <behave@ietf.org>; Wed, 7 Mar 2012 22:34:20 -0800 (PST)
Received: from mail6-db3-R.bigfish.com (10.3.81.227) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Mar 2012 06:34:20 +0000
Received: from mail6-db3 (localhost [127.0.0.1]) by mail6-db3-R.bigfish.com (Postfix) with ESMTP id 0A34820329; Thu, 8 Mar 2012 06:34:20 +0000 (UTC)
X-SpamScore: -38
X-BigFish: VS-38(zzbb2dI9371Ic89bh179cM1432Nc857hzz1202hzz1033IL8275bh8275dh186Mz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail6-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=muraris@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ;
Received: from mail6-db3 (localhost.localdomain [127.0.0.1]) by mail6-db3 (MessageSwitch) id 1331188458216741_28887; Thu, 8 Mar 2012 06:34:18 +0000 (UTC)
Received: from DB3EHSMHS008.bigfish.com (unknown [10.3.81.238]) by mail6-db3.bigfish.com (Postfix) with ESMTP id 24D1F380045; Thu, 8 Mar 2012 06:34:18 +0000 (UTC)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS008.bigfish.com (10.3.87.108) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Mar 2012 06:34:17 +0000
Received: from TK5EX14MBXC298.redmond.corp.microsoft.com ([169.254.1.119]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0283.004; Thu, 8 Mar 2012 06:34:15 +0000
From: Murari Sridharan <muraris@microsoft.com>
To: Dmitry Anipko <Dmitry.Anipko@microsoft.com>, marcelo bagnulo braun <marcelo@it.uc3m.es>
Thread-Topic: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
Thread-Index: Acz89Xq07tx51T/RTcC0uSBh3Nq7LQ==
Date: Thu, 08 Mar 2012 06:34:14 +0000
Message-ID: <EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6@TK5EX14MBXC298.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_EF5EF2B13ED09B4F871D9A0DBCA463C21C2CC1F6TK5EX14MBXC298r_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-Mailman-Approved-At: Thu, 08 Mar 2012 09:57:25 -0800
Cc: "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] NAT64: clarification on RST handling in V6 FIN RCV state
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Mar 2012 06:34:22 -0000
X-List-Received-Date: Thu, 08 Mar 2012 06:34:22 -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: behave@ietf.org, 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:* 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