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

"Lee, Yiu" <Yiu_Lee@comcast.com> Wed, 09 May 2018 03:05 UTC

Return-Path: <Yiu_Lee@comcast.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 50F0612420B; Tue, 8 May 2018 20:05:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-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 jXahvjoXpORE; Tue, 8 May 2018 20:05:11 -0700 (PDT)
Received: from pacdcmhout02.cable.comcast.com (pacdcmhout02.cable.comcast.com [68.87.96.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91431200E5; Tue, 8 May 2018 20:05:10 -0700 (PDT)
X-AuditID: 4457600f-7a26a70000006996-7c-5af2656386d8
Received: from PACDCEX25.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by pacdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 32.7F.27030.36562FA5; Tue, 8 May 2018 23:05:07 -0400 (EDT)
Received: from PACDCEX28.cable.comcast.com (24.40.1.151) by PACDCEX25.cable.comcast.com (24.40.1.148) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 8 May 2018 23:05:08 -0400
Received: from PACDCEX28.cable.comcast.com ([fe80::3aea:a7ff:fe36:86d4]) by PACDCEX28.cable.comcast.com ([fe80::3aea:a7ff:fe36:86d4%19]) with mapi id 15.00.1365.000; Tue, 8 May 2018 23:05:08 -0400
From: "Lee, Yiu" <Yiu_Lee@comcast.com>
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, "Ramesh.R.Chandra@ril.com" <Ramesh.R.Chandra@ril.com>
CC: "ianfarrer@gmx.com" <ianfarrer@gmx.com>, "softwires@ietf.org" <softwires@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: [EXTERNAL] Re: [Softwires] ISP CGN logging inc. Destination ??
Thread-Index: AQHT50KIcm+HNUEGpU64XCtHrVT3wQ==
Date: Wed, 09 May 2018 03:05:06 +0000
Message-ID: <0D9E2A70-B381-4AD1-9279-1C69B931D8EB@comcast.com>
References: <56C7D96E-182F-4584-B190-DCD17957C01F@cisco.com> <95081DF2-FBE4-4B28-802E-13988B6DDF8D@gmx.com> <8433F1DD-3988-4DF6-B14D-3873B0F36CCB@cisco.com> <DE94262F-6C94-492A-B9F0-629160527B37@gmx.com> <ef2bbe951814477eae919a4abf9ae182@SHYDEXMBX08.in.ril.com> <77D9057C-0310-4D03-BCA9-DBFC17CE9055@Cable.Comcast.com> <6b552bbdcc4146aa97386eb609c70e27@SHYDEXMBX08.in.ril.com> <0041E033-2A33-40C8-AF67-B2FE050C4531@cisco.com>
In-Reply-To: <0041E033-2A33-40C8-AF67-B2FE050C4531@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
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: [96.114.156.7]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3608665505_1919637599"
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsXiEq4ko5uc+inK4MwCSYtNp6exW9yYdZPF 4u/fR8wWu2fuYLY4vGwrkwOrx5TfG1k97t5fyOSxZMlPJo8v/f+YA1iiuGxSUnMyy1KL9O0S uDL2dP5kLtjzgLFi0a15bA2MX08ydjFyckgImEjMeXubCcQWEtjFJHHpWFYXIxeQvZNR4seT BYwQzglGiXuNZ8Gq2ATUJFZvOMkGYosIpElcOnmXDaSIWaCRUWJV0zZWkISwgLfEuUezmCCK fCTWPp4MZetJ7P35kRnEZhFQkZj+cCLYIF4BO4m+XfeZIbZtZ5ZYt7sXqIGDg1PAVuLv7FyQ GkYBMYnvp9aAzWEWEJe49WQ+E8QLIhIPL55mg7BFJV4+/scK0ioKtGvSgRKIsI7E2etPoD42 kNi6dB8LhK0g0TNhOjPEyEqJD296mSHOEZQ4OfMJVI24xOEjO1gnMErOQrJ5FpKWWUhaZgFt ZhbwkFjwzxiiRFtiz62tzDD2k3cXWCFsLYkrNw6zY4pbS8z4dZANwlaUmNL9EKrGVOL10Y+M Cxi5VzFym1noWZjrWZrpGZpuYgQnlAT+HYxHp3scYhTgYFTi4d3n/ylKiDWxrLgy9xCjClD3 ow2rLzBKseTl56UqifDKGgOleVMSK6tSi/Lji0pzUosPMUpzsCiJ8zaf/hglJJCeWJKanZpa kFoEk2Xi4JRqYGRgOLXnVcwvKzFHy1NuAe0yH5zzyqeqbzS49qxe/3mLWFOMwDHuaxqLg9Y5 n59mnp+x77DcFpNVRo1PLk/8eU04UvfI75KCIqbrjL+W1sw/xfmqMPhJ+YyD175vrH6/5qz2 EjuvwAu/XxQtt3twQGPGaxVWQXd+MXbxTx5bdMMffT987p/6iT4lluKMREMt5qLiRAAPGUbQ MAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/rJ_1D2I1RoS7jL4Jp1hpMd6UoOo>
Subject: Re: [Softwires] [EXTERNAL] Re: 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: Wed, 09 May 2018 03:05:13 -0000

Let’s me be precise. This regulation must exist today. So there must exist a way to log the five-IPv4-tuple. If Ramesh combines the dhcpv6 logs with the current five-IPv4-tuple logs, will this be enough? 

 

From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
Date: Tuesday, May 8, 2018 at 5:42 PM
To: "Ramesh.R.Chandra@ril.com" <Ramesh.R.Chandra@ril.com>, "Lee, Yiu" <Yiu_Lee@Cable.Comcast.com>
Cc: "ianfarrer@gmx.com" <ianfarrer@gmx.com>, "softwires@ietf.org" <softwires@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [EXTERNAL] Re: [Softwires] ISP CGN logging inc. Destination ??

 

Agree with Ramesh. DHCP(v6) helps with logging source IP assignment, but that’s it.


The requirement here is about keeping track of not only source IP+port, but also destination IP+port per connection. DHCP(v6) doesn’t apply here.

 

-- 

Cheers,

Rajiv  

 

From: "Ramesh.R.Chandra@ril.com" <Ramesh.R.Chandra@ril.com>
Date: Tuesday, May 8, 2018 at 1:15 AM
To: "Yiu_Lee@comcast.com" <Yiu_Lee@comcast.com>
Cc: "ianfarrer@gmx.com" <ianfarrer@gmx.com>, Rajiv Asati <rajiva@cisco.com>, Softwires-wg list <softwires@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Subject: RE: [EXTERNAL] Re: [Softwires] ISP CGN logging inc. Destination ??

 

Not really. Need IPv4 because desitination IP is on IPv4.

 

Regds

ramesh chandra

M#: +91 90829 61303

O#: +91 22 7965 9762

 

-----Original Message-----

From: Lee, Yiu [mailto:Yiu_Lee@comcast.com] 

Sent: 07 May 2018 16:46

To: Ramesh R Chandra

Cc: ianfarrer@gmx.com; rajiva@cisco.com; softwires@ietf.org; int-area@ietf.org

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

 

Just a quick thought. Will the dhcpv6 logs help?

 

Sent from mobile device, pardon possible typo.

 

On May 7, 2018, at 7:06 AM, "Ramesh.R.Chandra@ril.com" <Ramesh.R.Chandra@ril.com> wrote:

Dear Ian,  thanks for clarifications.

Regulator in India mandated to preserve the following details for each flow.

1.    Source IP + Port (private for end subscriber device)

2.    Destination IP + Port (public)

3.    Translated IP + port (public)

4.    Date and time

There is no brainer and all this is available in NAT44. MAP being stateless, no such data available from MAP-BR. We are exploring alternate option on BR to create this data in MAP.

Pls advise.

Regds

ramesh

-----Original Message-----

From: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com]

Sent: 04 May 2018 17:28

To: Rajiv Asati (rajiva)

Cc: Softwires-wg list; int-area@ietf.org; Ramesh R Chandra

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

Hi Rajiv,

Please see inline.

Cheers,

Ian

On 4. May 2018, at 12:01, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote:

Ian,

Thanks for sharing the URL. While not explicit, “all metadata” would include both source and destination A+P. Is that the right interpretation?

[if - My understanding is that per-flow logging is necessary to meet 

the requirement, but I’m not familiar enough with the legislation to 

know what exactly needs to be stored.]

If an ISP were to use “binding” mode on the BR, then without using net flow/IPFIX, How could the compliance be achieved ?

[if - If there’s address sharing and the requirement is to provide an exact match to a data retention request (in some countries, a list of e.g. 16 users is OK), then AFAICS, you have to use IPFIX.

The implementation problem for this is compounded by the lack of state 

table on most BR implementations (e.g. how do you know when a UDP 

session has completed without state for that flow?)]

"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 

are confidential and may be privileged. If you are not the intended 

recipient. you are hereby notified that any review. re-transmission. 

conversion to hard copy. copying. circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email.

and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 

The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."

_______________________________________________

Softwires mailing list

Softwires@ietf.org

https://www.ietf.org/mailman/listinfo/softwires

"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 

are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 

review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 

strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 

and delete this message and any attachments from your system.

 

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 

The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."