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

[ianfarrer]

Hi Rajiv,

Please see inline.

Cheers,
Ian

> On 4. May 2018, at 12:01, Rajiv Asati (rajiva)  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?)]

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[Dave O'Reilly]

Hi Rajiv,

> On 4 May 2018, at 11:36, Rajiv Asati (rajiva)  wrote:
> 
>> 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. 
> 

Good point. Will incorporate in next draft.
>  
>> 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. 
> 

I completely agree with you. In fact, I have already started to investigate the 
IPv6 attribution issues. See 
https://datatracker.ietf.org/doc/draft-daveor-ipv6-crime-attribution/. This 
document is still preliminary so I would be very interested in any feedback you 
might have.

Best,
daveor

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[Rajiv Asati (rajiva)]

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 
> 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) 
> 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-a...@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[Rajiv Asati (rajiva)]

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 an ISP were to use “binding” mode on the BR, then without using net 
flow/IPFIX, How could the compliance be achieved ?

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services


On May 4, 2018, at 4:16 AM, "ianfar...@gmx.com" 
> wrote:

Hi,

As another data point on this topic, the storing of A+P data is also mandated 
in Hungary. From the Hungary paragraph of the 2016 EU report into 
implementation of the Data Retention Directive 
(http://fra.europa.eu/en/theme/information-society-privacy-and-data-protection/data-retention):

"The new law obliges electronic and IT service providers that allow encrypted 
communication through their services to store all metadata related to such 
communications for one year. It thus widens the scope of data retention."

Translated: A+P retention.

Cheers,
Ian




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
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

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

[ianfarrer]

Hi,

As another data point on this topic, the storing of A+P data is also mandated 
in Hungary. From the Hungary paragraph of the 2016 EU report into 
implementation of the Data Retention Directive 
(http://fra.europa.eu/en/theme/information-society-privacy-and-data-protection/data-retention):

"The new law obliges electronic and IT service providers that allow encrypted 
communication through their services to store all metadata related to such 
communications for one year. It thus widens the scope of data retention."

Translated: A+P retention.

Cheers,
Ian


> 

> 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
> ___
> Softwires mailing list
> Softwires@ietf.org 
> https://www.ietf.org/mailman/listinfo/softwires 
> 
___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires