Re: [Softwires] ISP CGN logging inc. Destination ??

<mohamed.boucadair@orange.com> Mon, 07 May 2018 05:30 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132951270A7; Sun, 6 May 2018 22:30:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c_TkUlfiTjw; Sun, 6 May 2018 22:30:08 -0700 (PDT)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B23EB12704A; Sun, 6 May 2018 22:30:07 -0700 (PDT)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 1F73112084A; Mon, 7 May 2018 07:30:06 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id E838E60072; Mon, 7 May 2018 07:30:05 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0389.001; Mon, 7 May 2018 07:30:05 +0200
From: mohamed.boucadair@orange.com
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, Softwires-wg list <softwires@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
CC: "Ramesh.R.Chandra@ril.com" <Ramesh.R.Chandra@ril.com>
Thread-Topic: ISP CGN logging inc. Destination ??
Thread-Index: AQHT4yi6QsPwS4mEj0Wx5sa9RJtTQaQjwPWw
Date: Mon, 07 May 2018 05:30:05 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DF150A2@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <56C7D96E-182F-4584-B190-DCD17957C01F@cisco.com>
In-Reply-To: <56C7D96E-182F-4584-B190-DCD17957C01F@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.2]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DF150A2OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/nWpQvCuhzZx0H8UJjPZMc9aR07s>
Subject: Re: [Softwires] ISP CGN logging inc. Destination ??
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 May 2018 05:30:10 -0000

Hi Rajiv,

Please check RFC6888 which says the following:

   REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
      required to do so for administrative reasons.

Cheers,
Med

De : Softwires [mailto:softwires-bounces@ietf.org] De la part de Rajiv Asati (rajiva)
Envoyé : jeudi 3 mai 2018 23:50
À : Softwires-wg list; int-area@ietf.org
Cc : Ramesh.R.Chandra@ril.com
Objet : [Softwires] ISP CGN logging inc. Destination ??

Is there an RFC (besides 6269) that encourages / discourages CGN logging of destination IP+Port if source IP+port is already logged?

RFC6269 does mention the below, as compared to the server side logging of source IP+port -

// logging the destination address on the NAT is inferior
   to logging the source port at the server.
https://tools.ietf.org/html/rfc6269
//

(BTW, having both source+destination in the NAT log implicitly means no bulk allocation of source ports possible)

Separately, this prohibits using stateless NAT based solutions such as MAP or using deterministic NAT, since there is no logging in such solutions. If such a guideline was also mandated for native IPv6, then it would pose an interesting deployment issue.

--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

PS: Few may be aware of Govt. of India’s mandate* to log both source and destination IP+port pair.
Click on “Parameter to be stored in SYS Log of Network Address Translation (NAT) for Internet Access” on this page - https://www.corestack.io/blog/the-log-mandate-enabling-indian-isps-to-adhere-to-dot-compliance-rules/

PS:
https://tools.ietf.org/html/rfc6302
https://tools.ietf.org/html/rfc7422


Session and service continuity