Subject: [sunset4] FW: New Version Notification for draft-donley-behave-deterministic-cgn-04.txt

From: Chris Donley <[email-masked]>
Date: Wed, 11 Jul 2012 15:21:47 -0600

I would like to discuss deterministic-cgn in Vancouver.  In answer to the
three questions:

1) describe the problem to be solved and show that there is
widespread demand for a solution

Abuse response in a Carrier Grade NAT environment requires Service
Providers to be able to map a subscriber¹s inside address with the address
used
on the public Internet. Unfortunately, many Carrier Grade NAT
abuse-response
solutions require per-connection logging. Research indicates that such
logging
is not scalable to many residential broadband services.
 
CableLabs has been approached by a group of Internet Service
Providers and international public safety organizations to identify a
solution
to this problem.  In addition, we
discussed this approach at the last two IETF meetings, and heard from ISPs
that
there is widespread demand for this solution.

2) demonstrate that the problem can not be solved with existing
Technologies

The
existing solutions  per-connection logging and bulk-port logging still
pose an impact
on ISPs and public safety officials  for
logging and searching. Our approach deterministically maps internal
addresses
to {external address + port range} in such a way as to be able to
algorithmically calculate the mapping.
Only inputs and configuration of the algorithm need to be logged. This
approach reduces both logging volume and subscriber identification times
while
increasing subscriber privacy (i.e. by not logging activity).

3)
provide a description of the proposed solution along with its impact on
current
IPv4-only use and justification that it does not harm or delay the
deployment
of IPv6

The
solution described in this document is applicable to Carrier Grade NAT
transition technologies (e.g. NAT444, DS-Lite, and NAT64). The authors
acknowledge that native IPv6 will offer subscribers a better experience
than
CGN. However, many CPE devices only support IPv4. Likewise, only
approximately
4% of the top 1 million websites are available using IPv6. Accordingly,
deterministic CGN should in no way be understood as making CGN a
replacement
for IPv6 service.  The authors encourage
device manufacturers to consider RFC 6540 and include IPv6 support.  In
the interim, however, CGN has already been
deployed in some ISP networks.
Deterministic CGN will provide ISPs with the ability to quickly respond
to public safety requests without requiring excessive infrastructure,
operations, and bandwidth to support per-connection logging.

The latest update addresses each of these in the text.
Chris
-- 
Chris Donley
CCIE, CISSP, SCiPM
Director - Network Technologies
CableLabs®
858 Coal Creek Circle
Louisville, CO 80027
303-661-3480 (v)

On 7/11/12 3:02 PM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-donley-behave-deterministic-cgn-04.txt
>has been successfully submitted by Chris Donley and posted to the
>IETF repository.
>
>Filename:	 draft-donley-behave-deterministic-cgn
>Revision:	 04
>Title:		 Deterministic Address Mapping to Reduce Logging in Carrier Grade
>NAT Deployments
>Creation date:	 2012-07-11
>WG ID:		 Individual Submission
>Number of pages: 14
>URL:             
>http://www.ietf.org/internet-drafts/draft-donley-behave-deterministic-cgn-
>04.txt
>Status:          
>http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn
>Htmlized:        
>http://tools.ietf.org/html/draft-donley-behave-deterministic-cgn-04
>Diff:            
>http://tools.ietf.org/rfcdiff?url2=draft-donley-behave-deterministic-cgn-0
>4
>
>Abstract:
>   Abuse response in a Carrier Grade NAT environment requires Service
>   Providers to be able to map a subscriber's inside address with the
>   address used on the public Internet.  Unfortunately, many Carrier
>   Grade NAT abuse-response solutions require per-connection logging.
>   Research indicates that such logging is not scalable to many
>   residential broadband services.  This document suggests a way to
>   manage Carrier Grade NAT translations in such a way as to
>   significantly reduce the amount of logging required while providing
>   traceability for abuse response.  While the authors acknowledge that
>   IPv6 is a preferred solution, Carrier Grade NAT is a reality in many
>   networks, and is needed in situations where either customer equipment
>   or Internet content only supports IPv4; this approach should in no
>   way slow the deployment of IPv6.
>
>
>                  
>        
>
>
>The IETF Secretariat

---

From: "George, Wes" <[email-masked]>
Date: Tue, 17 Jul 2012 14:49:14 -0400

If you are not familiar with this document from its prior discussion in other WGs, please be aware that there is an IPR disclosure for it: https://datatracker.ietf.org/ipr/1617/

I note that there are currently no licensing terms, and thus direct the authors to section 6.5 of RFC3979:

   Since IPR disclosures will be used by IETF working groups during
   their evaluation of alternative technical solutions, it is helpful if
   an IPR disclosure includes information about licensing of the IPR in
   case Implementing Technologies require a license.  Specifically, it
   is helpful to indicate whether, upon approval by the IESG for
   publication as RFCs of the relevant IETF specification(s), all
   persons will be able to obtain the right to implement, use,
   distribute and exercise other rights with respect to an Implementing
   Technology a) under a royalty-free and otherwise reasonable and non-
   discriminatory license, or b) under a license that contains
   reasonable and non-discriminatory terms and conditions, including a
   reasonable royalty or other payment, or c) without the need to obtain
   a license from the IPR holder.

   The inclusion of licensing information in IPR disclosures is not
   mandatory but it is encouraged so that the working groups will have
   as much information as they can during their deliberations.

Thanks,

Wes George, Sunset4 co-chair

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Chris Donley
> Sent: Wednesday, July 11, 2012 5:22 PM
> To: [email-masked]
> Subject: [sunset4] FW: New Version Notification for draft-donley-behave-
> deterministic-cgn-04.txt
>
> I would like to discuss deterministic-cgn in Vancouver.  In answer to
> the three questions:
>
> 1) describe the problem to be solved and show that there is widespread
> demand for a solution
>
>
> Providers to be able to map a subscriber¹s inside address with the
> address used on the public Internet. Unfortunately, many Carrier Grade
> NAT abuse-response solutions require per-connection logging. Research
> indicates that such logging is not scalable to many residential
> broadband services.
>
> CableLabs has been approached by a group of Internet Service Providers
> and international public safety organizations to identify a solution to
> this problem.  In addition, we discussed this approach at the last two
> IETF meetings, and heard from ISPs that there is widespread demand for
> this solution.
>
>
> pose an impact on ISPs and public safety officials  for logging and
> searching. Our approach deterministically maps internal addresses to
> {external address + port range} in such a way as to be able to
> while increasing subscriber privacy (i.e. by not logging activity).
>
>
> 3)
> current IPv4-only use and justification that it does not harm or delay
> the deployment of IPv6
>
>
> The
> than CGN. However, many CPE devices only support IPv4. Likewise, only
> approximately 4% of the top 1 million websites are available using IPv6.
> Accordingly, deterministic CGN should in no way be understood as making
> CGN a replacement for IPv6 service.  The authors encourage device
> manufacturers to consider RFC 6540 and include IPv6 support.  In the
> interim, however, CGN has already been deployed in some ISP networks.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.