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

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Tue, 08 May 2018 21:42 UTC

Return-Path: <rajiva@cisco.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 40A5C12EAF5; Tue, 8 May 2018 14:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 PAK1Xj7k7hvu; Tue, 8 May 2018 14:42:37 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE59312EAE9; Tue, 8 May 2018 14:42:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22176; q=dns/txt; s=iport; t=1525815757; x=1527025357; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9MPp0ptEjKw0/+V+1ZdWwSDOoQOuWnXxn+UmmeFXECU=; b=KtEHcWyw56Ul2EYLZ8QaSqBoB6mXK/a+sPzRuYGAk3djywIiBe0i13W0 cBZLLp3N4pFVn8FH61IyqE2phxxw5tVfbF7/7Exv4ExOtE7w5TcremIYk BRjsx7TzRQY4c2y1ZRTnhysucPDjiLs6Mj1k7CYzJgamcuObiIw3Ycxvd M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AbAQA9GfJa/4wNJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYJNdmEXYygKg2WIAox2gXmBD5MoFIFkCyWERwIagkshNBgBAgEBAQEBAQJsHAyFKAEBAQEDI1YQAgEIEQMBAigDAgICMBQJCAIEAQ0FG4MyAXJkD6YkgSCCHIhCgkMFiCWBVD+BMoJogxEBAQOBICc2FoJKMIIkAoggkAoIAoVjiGiBNYNghjyBEYlGhl8CERMBgSQBHDiBUnAVOyoBghgJiFeCMIU+bwGQQoEYAQE
X-IronPort-AV: E=Sophos;i="5.49,379,1520899200"; d="scan'208,217";a="389369262"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2018 21:42:36 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w48LgaYw025729 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 May 2018 21:42:36 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 8 May 2018 16:42:36 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Tue, 8 May 2018 16:42:36 -0500
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.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: AQHT4yi6QsPwS4mEj0Wx5sa9RJtTQaQjwPWwgAK0bwA=
Date: Tue, 08 May 2018 21:42:36 +0000
Message-ID: <20190EE2-2FBF-4AB3-A3F4-6F7B6BA89AD6@cisco.com>
References: <56C7D96E-182F-4584-B190-DCD17957C01F@cisco.com> <787AE7BB302AE849A7480A190F8B93302DF150A2@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF150A2@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.c.0.180410
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.230.34]
Content-Type: multipart/alternative; boundary="_000_20190EE22FBF4AB3A3F46F7B6BA89AD6ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/neVSDSr53GhjOLVA4NTS-8Uq018>
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: Tue, 08 May 2018 21:42:40 -0000

Thanks, Med. This makes it very explicit.

--
Cheers,
Rajiv

From: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
Date: Monday, May 7, 2018 at 1:30 AM
To: Rajiv Asati <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>
Subject: RE: ISP CGN logging inc. Destination ??

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