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

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Fri, 04 May 2018 10:36 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 2A2E01241F5; Fri, 4 May 2018 03:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, 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 ZU8Nbez_EGVN; Fri, 4 May 2018 03:36:02 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89139120726; Fri, 4 May 2018 03:36:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15881; q=dns/txt; s=iport; t=1525430162; x=1526639762; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=S2q8XJ7KOpUwXerzc0YFLCCtlVRZcrjpbrdCeNM/M5M=; b=cEtOj5K3RN1L4S12IfS6UO8slR4P5Y8hX/E5KVOZNGvMd77oN1RP3N+E g/lWVENJoUAVA95jxJwf18sxG6MU7j6hQxmuwQ3nkhW6mdjmtAUPCcBaJ U5oBHkoRBx/nGgocNhTuCv5oiyBAVes1pkLkIGgclU6jruJGWhzotqkLT M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AHAQBzNuxa/4ENJK1cGQEBAQEBAQEBAQEBAQcBAQEBAYNEYXoog22IAoxwgT07gQ+OKoRxFIFkCxgBDIRHAhqCGyE0GAECAQEBAQEBAmwcDIUpAgEDAQEhRAcLEAIBCD8DAgICJQsUEQIEDgUbhBRkD6YCgSCCHIhCgj0FiBYPgVQ/gTKCMwcugxEBAQECgSAKAQsGAgEIgxYwgiQCmBsIAoViiGiMWYlBhl0CERMBgSQBHDhhcXAVOyoBghiCIBeGKYIwhT5vAY1ygkYBAQ
X-IronPort-AV: E=Sophos;i="5.49,362,1520899200"; d="scan'208,217";a="109704742"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2018 10:36:01 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w44Aa1OT007028 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 May 2018 10:36:01 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; Fri, 4 May 2018 05:36:00 -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; Fri, 4 May 2018 05:36:00 -0500
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Dave O'Reilly <rfc@daveor.com>
CC: Softwires-wg list <softwires@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "Ramesh.R.Chandra@ril.com" <Ramesh.R.Chandra@ril.com>
Thread-Topic: [Int-area] ISP CGN logging inc. Destination ??
Thread-Index: AQHT4yi6QsPwS4mEj0Wx5sa9RJtTQaQfEkOAgABOz90=
Date: Fri, 04 May 2018 10:36:00 +0000
Message-ID: <7E84374E-B86E-4CB7-86A9-DAA6D75D6F05@cisco.com>
References: <56C7D96E-182F-4584-B190-DCD17957C01F@cisco.com>, <0CACF256-D50A-4D0D-BE63-B6A79016A966@daveor.com>
In-Reply-To: <0CACF256-D50A-4D0D-BE63-B6A79016A966@daveor.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_7E84374EB86E4CB786A9DAA6D75D6F05ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/TfS0YsjznXKulv3Rs23KxDzKPLc>
Subject: Re: [Softwires] [Int-area] 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: Fri, 04 May 2018 10:36:05 -0000

Dave,

Thanks. Pls see inline,

For what it’s worth, my Internet draft also discourages connection/destination logging - draft-daveor-cgn-logging-04 (see section 3).

Besides the size of the log data, the CGN implementations may take a performance hit if destination A+P also needs to be logged (e.g. connection log), resulting in increased CGN investment.


outlined the regulatory alternatives that are the only options left for dealing with CGN crime attribution (if source port logging at internet facing servers does not become routine) - one of which was this form of connection logging.

The need for connection logging may go beyond the concern of size of logging data - user privacy.  And this carries over to not only A+P techniques, but also IPv6. IOW, this concern may not be limited to address sharing techniques.

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services


On May 3, 2018, at 8:58 PM, Dave O'Reilly <rfc@daveor.com<mailto:rfc@daveor.com>> wrote:

Hi Rajiv,

For what it’s worth, my Internet draft also discourages connection/destination logging - draft-daveor-cgn-logging-04 (see section 3).

Re the Indian government mandated connection logging that you mentioned - I was not aware of this but it is a piece of strong supporting evidence for exactly the point I was making in an email earlier this week (https://www.ietf.org/mail-archive/web/int-area/current/msg06442.html) where I outlined the regulatory alternatives that are the only options left for dealing with CGN crime attribution (if source port logging at internet facing servers does not become routine) - one of which was this form of connection logging.

As I said at the time, the crime attribution information gap introduced by CGN is a problem right now, and something is going to have be done about it, either by the “internet” (as I’m trying to advocate for), or if not, then by regulatory action that will be introduced in individual jurisdictions in due course. I reiterate the point I made at the time: when ISP regulators get their hands on a problem, they come up with ISP-centric solutions, all of which are far worse from a privacy point of view than source port logging.

I predict that many other national ISP regulators will be forced to act on this problem in the coming years, and in the absence of meaningful alternatives will mandate similar logging.

daveor


On 3 May 2018, at 22:50, Rajiv Asati (rajiva) <rajiva@cisco.com<mailto:rajiva@cisco.com>> wrote:

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
_______________________________________________
Int-area mailing list
Int-area@ietf.org<mailto:Int-area@ietf.org>
https://www.ietf.org/mailman/listinfo/int-area