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

[Lee, Yiu]

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" , "softwires@ietf.org" 
, "int-a...@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-a...@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; softwires@ietf.org; int-a...@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-a...@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” 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 

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

[Rajiv Asati (rajiva)]

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-a...@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; 
softwires@ietf.org; 
int-a...@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-a...@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” 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."

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

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

Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

[Bernie Volz (volz)]

Hi Ian:

Thanks … suggested text changes look good. I would think it best to reference 
3315bis … hopefully it won’t hold up publication of this draft since it may 
take RFC Editor a bit longer to process the 3315bis document, but they also 
will have a head start. (If it does hold it up and we need to expedite release 
of this draft as an RFC, we can always ask for reference to change to 3315.)


  *   Bernie

From: Ian Farrer 
Date: Tuesday, May 8, 2018 at 10:10 AM
To: Bernie Volz 
Cc: "dh...@ietf.org" , 
"draft-ietf-dhc-dhcp4o6-saddr-...@ietf.org" 
, "softwires@ietf.org" 

Subject: Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - 
EXTENDED - Respond by April 17, 2018

Hi Bernie,

Many thanks for the review. I’ve had a look through your comments and they all 
look straightforward enough. They will be in the next version with Tomek’s 
comments.

Here’s my suggestions in response to a couple of your comments:

SECTION 9:

-  More of a question – do the new options or procedures add any new or 
different considerations? If not, great.

There is one case that I think is missed. I’ve update the Security 
Considerations section to add the following text:

  A rogue client could attempt to use the mechanism described
  in "Changing the Bound IPv6 Softwire Source Address” to redirect IPv4 
traffic
  intended for another client to itself. This would be performed by
  sending a DHCPREQUEST message for another client's active IPv4
  lease containing the attacker's softwire IPv6 address in
  OPTION_DHCP4O6_S46_SADDR.

  For such an attack to be effective, the attacker would
  need to know both the client identifier and active IPv4
  address lease currently in use by another client. The risk
  of this can be reduced by using a client identifier format
  which is not easily guessable, e.g. by including a time
  component for when the client identifier was generated
  (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).


-  And, it is rather odd that DHCPv4 (RFC2131) and DHCPv6 
(draft-ietf-dhc-rfc3315bis) aren’t referenced in the document. They are 
implicit because RFC7341 is referenced, but not always clear that this is the 
best way to go. But I didn’t find any easy way to incorporate these references 
directly.

I’ve added the following to Section 4. Solution Overview:

In order to provision a softwire, both IPv6 and IPv4 configuration
needs to be passed to the client. To map this to the DHCP 4o6
configuration process, the IPv6 configuration is carried in
DHCPv6 options [I-D.ietf-dhc-rfc3315bis], carried
inside the DHCPv6 message DHCPV4-RESPONSE (21)
sent by the server.

And:

IPv4 configuration is carried in DHCPv4 messages ,
(inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism
described in .

The normative refs. are updated with these as well.

BTW, should I be referencing RFC3315 or the -bis version as normative at this 
stage?

Thanks,
Ian

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

Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

[ianfarrer]

Hi Bernie,

Many thanks for the review. I’ve had a look through your comments and they all 
look straightforward enough. They will be in the next version with Tomek’s 
comments.

Here’s my suggestions in response to a couple of your comments:

SECTION 9:
 
-  More of a question – do the new options or procedures add any new or 
different considerations? If not, great.

There is one case that I think is missed. I’ve update the Security 
Considerations section to add the following text:

  A rogue client could attempt to use the mechanism described
  in "Changing the Bound IPv6 Softwire Source Address” to redirect IPv4 
traffic
  intended for another client to itself. This would be performed by
  sending a DHCPREQUEST message for another client's active IPv4
  lease containing the attacker's softwire IPv6 address in
  OPTION_DHCP4O6_S46_SADDR.

  For such an attack to be effective, the attacker would
  need to know both the client identifier and active IPv4
  address lease currently in use by another client. The risk
  of this can be reduced by using a client identifier format 
  which is not easily guessable, e.g. by including a time 
  component for when the client identifier was generated
  (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).


> -  And, it is rather odd that DHCPv4 (RFC2131) and DHCPv6 
> (draft-ietf-dhc-rfc3315bis) aren’t referenced in the document. They are 
> implicit because RFC7341 is referenced, but not always clear that this is the 
> best way to go. But I didn’t find any easy way to incorporate these 
> references directly.

I’ve added the following to Section 4. Solution Overview:

In order to provision a softwire, both IPv6 and IPv4 configuration
needs to be passed to the client. To map this to the DHCP 4o6
configuration process, the IPv6 configuration is carried in
DHCPv6 options [I-D.ietf-dhc-rfc3315bis], carried
inside the DHCPv6 message DHCPV4-RESPONSE (21) 
sent by the server.

And:

IPv4 configuration is carried in DHCPv4 messages ,
(inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism
described in .

The normative refs. are updated with these as well.

BTW, should I be referencing RFC3315 or the -bis version as normative at this 
stage?

Thanks,
Ian

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