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

[Rajiv Asati (rajiva)]

For native ipv4 communication (or ipv6 communication for that matter), 
netflow/IPFIX are the in-band means to help log the IPv4-tuple (or IPv6-tuple) 
information.

Sure, that can help.

--
Cheers,
Rajiv

From: "ramesh.r.chan...@ril.com" 
Date: Wednesday, May 9, 2018 at 3:25 AM
To: "yiu_...@comcast.com" , Rajiv Asati 
Cc: "ianfar...@gmx.com" , Softwires-wg list 
, "int-area@ietf.org" 
Subject: RE: [EXTERNAL] Re: [Softwires] ISP CGN logging inc. Destination ??

Hi Lee,  good thought. If we enable 5 tuple on BR for IPv4, required DA+P shall 
meet DA+P requirement. Using SA+P from 5-tuple should help to correlate with 
user IP based on DHCP assignment.

Key here is on BR to do 5-tuple after de-encapsulation of IPv6. Rajiv, pls 
check if we can do this on ASR9k as BNG.


Regds
Ramesh

From: Lee, Yiu [mailto:yiu_...@comcast.com]
Sent: 09 May 2018 08:35
To: Rajiv Asati (rajiva); Ramesh R Chandra
Cc: ianfar...@gmx.com; softwi...@ietf.org; int-area@ietf.org
Subject: Re: [EXTERNAL] Re: [Softwires] ISP CGN logging inc. Destination ??

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)" >
Date: Tuesday, May 8, 2018 at 5:42 PM
To: "ramesh.r.chan...@ril.com" 
>, "Lee, Yiu" 
>
Cc: "ianfar...@gmx.com" 
>, 
"softwi...@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.chan...@ril.com" 
>
Date: Tuesday, May 8, 2018 at 1:15 AM
To: "yiu_...@comcast.com" 
>
Cc: "ianfar...@gmx.com" 
>, Rajiv Asati 
>, Softwires-wg list 
>, 
"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_...@comcast.com]
Sent: 07 May 2018 16:46
To: Ramesh R Chandra
Cc: ianfar...@gmx.com; 
raj...@cisco.com; 
softwi...@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.chan...@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: ianfar...@gmx.com [mailto:ianfar...@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) 
> 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” 

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

[Rajiv Asati (rajiva)]

Thanks, Med. This makes it very explicit.

--
Cheers,
Rajiv

From: "mohamed.boucad...@orange.com" 
Date: Monday, May 7, 2018 at 1:30 AM
To: Rajiv Asati , Softwires-wg list , 
"int-area@ietf.org" 
Cc: "ramesh.r.chan...@ril.com" 
Subject: RE: ISP CGN logging inc. Destination ??

Hi Rajiv,

Please check RFC6888 which says the following:

   REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
  required to do so for administrative reasons.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Rajiv Asati 
(rajiva)
Envoyé : jeudi 3 mai 2018 23:50
À : Softwires-wg list; int-area@ietf.org
Cc : ramesh.r.chan...@ril.com
Objet : [Softwires] ISP CGN logging inc. Destination ??

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

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

[mohamed.boucadair]

Hi Rajiv,

Please check RFC6888 which says the following:

   REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
  required to do so for administrative reasons.

Cheers,
Med

De : Softwires [mailto:softwires-boun...@ietf.org] De la part de Rajiv Asati 
(rajiva)
Envoyé : jeudi 3 mai 2018 23:50
À : Softwires-wg list; int-area@ietf.org
Cc : ramesh.r.chan...@ril.com
Objet : [Softwires] ISP CGN logging inc. Destination ??

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

Re: [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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

[Dave O'Reilly]

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

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area