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

[[e-mail]]

Hi Jordan,

Please see inline below.

Thanks,
Ian

> On 9. May 2018, at 21:38, Gottlieb, Jordan J <[e-mail]> wrote:
> 
> If I understand this correctly it appears that requirement #1 would dictate the capability must be deployed on the CE.  The way I read it you are attempting to retain the pre-NAPT client address and port.  For the particular use case, is the CPE managed by the service provider?  If so, why not originate the logging from the CPE as it has the necessary visibility and state maintenance to meet all the requirements?

[if – This is a possibility in some networks, but in many countries (most of Europe AFIAK], SP’s must allow customers to attach their own equipment so this can’t be considered a secure device for meeting data retention regulations.]

>  
> There was also a comment in this thread regarding UDP and session completion.  I don’t think this is practical on the BR as support for asymmetrical routing could result in incomplete session information on a particular BR (you would have to piece it together) as exit transit BR could be different from the return transit BR.  The only device with a complete view of the flow is the CE in this case as well.

[if – I agree that the collection is complicated if you have multiple BRs, but as stated above, I don’t see the CE being a viable solution for many deployments.]

>  
> Assuming CPE is not an option, MAP-T , and that requirement #1 is not the privately addressed customer endpoint (laptop, tablet, smartphone, etc..) one could use netflow pre-BR (IPv6) and some simple program to convert to the required metadata.  Destination address is trivial as it is a fixed set of bits within the DMR(s).  Source address is not hard as long as the conversion program has an accurate list of active mapping rules.  Obviously sampling rate comes into play but I believe we have the same issue with IPFIX.

[if - I’m not sure I follow this proposal. Would the pre-BR device still identify flows, just at a different offset within the header? Would the metadata conversion take place on the same device?]


>  
> Cheers,
>  
> Jordan
>  
> From: Softwires [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of [e-mail] <mailto:[e-mail]>
> Sent: Wednesday, May 09, 2018 1:31 AM
> To: Rajiv Asati (rajiva); [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Subject: Re: [Softwires] ISP CGN logging inc. Destination ??
>  
> Hi Rajiv,
>  
> What concerns me with this requirement is that it nullifies one of the motivations for stateless address sharing:
> https://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-05#section-3.1.3 <https://tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-05#section-3.1.3>(Logging - No Need for Dynamic Binding Notifications)
>  
> especially, this part:
>  
>    Some Service Providers have a requirement to use only existing
>    logging systems and to avoid introducing new ones (mainly because of
>    Capital Expenditure (CAPEX) considerations).  This requirement is
>    easily met with stateless solutions.
>  
> Cheers,
> Med
>  
> De : Softwires [mailto:[e-mail] <mailto:[e-mail]>] De la part de Rajiv Asati (rajiva)
> Envoyé : mardi 8 mai 2018 23:43
> À : [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Cc : [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Objet : Re: [Softwires] [EXTERNAL] Re: 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: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, May 8, 2018 at 1:15 AM
> To: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>, Rajiv Asati <[e-mail] <mailto:[e-mail]>>, Softwires-wg list <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: RE: [EXTERNAL] Re: [Softwires] ISP CGN logging inc. Destination ??
>  
> Not really. Need IPv4 because desitination IP is on IPv4. <>
>  
> Regds
> ramesh chandra
> M#: [phone]
> O#: [phone]
>  
> -----Original Message-----
> From: Lee, Yiu [mailto:[e-mail] <mailto:[e-mail]>]
> Sent: 07 May 2018 16:46
> To: Ramesh R Chandra
> Cc: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> 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, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>> 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: [e-mail] <mailto:[e-mail]> [mailto:[e-mail] <mailto:[e-mail]>]
> Sent: 04 May 2018 17:28
> To: Rajiv Asati (rajiva)
> Cc: Softwires-wg list; [e-mail] <mailto:[e-mail]>; 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) <[e-mail] <mailto:[e-mail]>> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/softwires <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."
>  
> The contents of this e-mail message and 
> any attachments are intended solely for the 
> addressee(s) and may contain confidential 
> and/or legally privileged information. If you
> are not the intended recipient of this message
> or if this message has been addressed to you 
> in error, please immediately alert the sender
> by reply e-mail and then delete this message 
> and any attachments. If you are not the 
> intended recipient, you are notified that 
> any use, dissemination, distribution, copying,
> or storage of this message or any attachment 
> is strictly prohibited. _______________________________________________
> Softwires mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/softwires <https://www.ietf.org/mailman/listinfo/softwires>