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

I expect Ramesh has already had a way to log dst IP and port if this is required by regulators.

Sent from mobile device, pardon possible typo.

> On May 7, 2018, at 7:28 AM, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> wrote:
> 
> Hi Yiu, 
> 
> This may help but this is not sufficient if supplying "Destination IP + Port (public)" is required. 
> 
> Technically the BR may extract and record the destination IPv4 address/port and source IPv6 prefix when doing its stateless decapsulation/translation, but this is not a "native" feature of a BR/lwAFTR. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Lee, Yiu
>> Envoyé : lundi 7 mai 2018 13:16
>> À : Ramesh.R.Chandra@ril.com
>> Cc : softwires@ietf.org; int-area@ietf.org; ianfarrer@gmx.com
>> Objet : Re: [Int-area] [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
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area