Subject: Re: [sunset4] review of draft-chen-sunset4-cgn-port-allocation

From: "George, Wes" <[email-masked]>
Date: Wed, 24 Sep 2014 22:02:18 -0400

Authors, you have a draft that will expire in a few weeks, as well as one
or more substantive reviews to address. Please push a revision, and then
we will do an adoption call so that we can discuss it further as a WG
draft during the meeting in honolulu.

Thanks,

Wes

On 8/13/14, 7:38 AM, "Tom Taylor" <[email-masked]> wrote:

>Lee, thank you for the time you put into this. I won't be able to deal
>with a lot of it personally because it requires my co-authors'
>knowledge. However, based on the IPR discussion at the meeting, I think
>we will split out deterministic CGN and let it go on its way as an
>individual draft. I can do that step and respond to as much of your
>review as I can. My co-authors can take the next step or advise me on
>the remaining issues.
>
>Tom Taylor
>
>On 24/07/2014 4:02 PM, Lee Howard wrote:
>> Doing my homework before the WG meeting this afternoon (and re-sending
>>from
>> the correct email address). . .
>>
>> This document needs significant work and reorganization.
>>
>> 1. Introduction
>> You say:
>> provide transparent routing to end hosts
>> I think it should say:
>> provide connectivity to end hosts
>>
>> Is it worth adding a sentence that these methods are only useful for
>>address
>> sharing methods, not NPT, and not encapsulation mechanisms?  It may not
>>be
>> necessary.
>> But, for instance, this sentence:
>> The CGN may not do Network Address Port Translation   (NAPT), but only
>> Network Address Translation (NAT) [RFC3022
>> <http://tools.ietf.org/html/rfc3022> ].
>>
>> THat's not an rfc2119 "may not," it's a description of one scenario.  I
>>had
>> to read it four times to figure that out; maybe it would be clearer as:
>>> The CGN might do Network Address Port Translation
>>>     (NAPT) without Network Address Translation (NAT) [RFC3022
>>> <http://tools.ietf.org/html/rfc3022> ].  In
>>>     this scenario, there is no concern about port assignment. When
>>>NAPT is
>>> involved, Š
>> Then you can enumerate the "does" and "does not" cases.
>>
>> independently of the particular flavour should be independent of the
>> particular flavour
>> Section 2.1 Port Consumption on NAT64
>>
>> This editorializing is unnecessary:
>>> Thanks to its simplicity and efficiency, NAT64 will likely be
>>>     deployed widely.
>>
>> Also,
>>   That is, a NAT44 will be deployed in an
>>     IPv4-only environment.
>> NAT44 + Native IPv6 is a perfectly reasonable and likely scenario, so
>>this
>> is untrue.  But this whole paragraph reads like a sales pitch for
>>NAT64: cut
>> it out.
>> Second paragraph:
>> One of the authors did a test comparison of port consumption on NAT64
>>     and NAT44.
>> Can you just cite the study?  Can you say, "A study of port consumption
>> [portstudy]. . ."  Though again, this whole study is only true to a
>>point in
>> time (though what version of the Alexa100 includes 43 sites with AAAA I
>> don't know).
>>
>> NAT64 "provides everyone with incentives to use IPv6,"
>> What incentives?  Does it buy ice cream for everyone who uses IPv6?
>>Either
>> explain, or, since defending the use of NAT64 is out of place in this
>> document, remove.
>>
>> [as v6 transition progresses,] it will be possible to relax the
>>     multiplexing ratio of IPv4 address sharing.
>> This is a good point.
>>
>>   change of IPv4 address will cause
>>     renumbering of IPv6 addresses.
>> I don't see how.  But again, I don't think this is intended as a NAT
>> discussion document, I thought it was just evaluating port allocation
>> methods.  Clean up that paragraph.
>>
>> It has been learned from subscribers'
>>            behaviors that the average number of sessions consumed by one
>>            user's device is around 200 to 300 ports.  Several devices
>>may
>>            appear behind a CPE.  Administrators may configure a range
>>            with 1000 ports to each CPE in fixed networks.
>> Avoid the passive voice.  Can you cite the 200-300 number?  Is that
>>true in
>> 2014, or for as long as this document is intended to be useful?  Yes,
>> administators may configure 1000 ports.  Or 1001.  Or 999.  Maybe what
>>you
>> mean is:
>>   1000 ports per subscriber household will provide enough room for
>>multiple
>> active users.  Administrators should monitor usage to adjust this
>>number if
>> users are being limited by this number, or if usage is so low that fewer
>> ports would be sufficient.
>>
>> non-contiguous port range for the
>>        sake of attack defense.
>> I think you explain this later in the document, but a reference to what
>>you
>> mean here would help.
>> A+P style [citation needed]
>>
>> 2.3.1  Use of the word "older" sounds perjorative.  Do you mean to imply
>> that NAT64 is obsolete?  Both in the title and text.
>> Stepping outside
>>     the boundaries of NAT64 for the moment, DS-Lite [RFC6333
>> <http://tools.ietf.org/html/rfc6333> ] refers to
>>     the cautions in [RFC6269 <http://tools.ietf.org/html/rfc6269> ] but
>>does
>> not specify any port allocation
>>     method.
>> First, that's pretty informal language.  Second, why point to DS-Lite
>> pointing to RFC6269; why not just point to RFC6269?
>> 2.3.2 Current Work on Stateless Transition Technologies
>> The proposals made in Section 3
>>
>><http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#sec
>>tio
>> n-3>  and Section 4
>>
>><http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#sec
>>tio
>> n-4>  do not apply
>>     to the current work in progress because that work has gone in
>>another
>>     direction.  That work includes:
>> Do we need to enumerate protocols that this work doesn't apply to?  If
>>so,
>> then I think this document is making normative references to those
>>protocols
>> (since their port allocation methods could, potentially, change until
>>they
>> are published), which will delay publication until lw4over6, MAP-T,
>>MAP-E,
>> 4rd have all been published.  Having said that, this may be a useful
>> comparison of possible methods, but I would try to limit it to that.
>> Sections 2.4.1 and 2.4.2 are excellent.
>> 2.4.3 s/alllocation/allocation
>> 3.1 US means U.S.?  Americans have higher traffic profiles?
>> 3.2 Remove sentence "Here is how dynamic allocation of port-ranges would
>> work in greater detail. "
>> 3.3 Section 11 of RFC6269 refers to fragmentation; you mean section 12.
>> Is
>> this section supposed to be a privacy considerations section?
>> Discoverability?  I think in the era of Pervasive Surveillance,
>>reference to
>> other IETF work is needed.  Also, please refer to RFC6302.
>> I'm not sure, though, that the discussion of server port logging is
>> appropriate in a document about how to allocate ports in CGN.  A
>>mention of
>> it makes sense, but evaluating the capability of different web servers,
>>with
>> a config guide, seems out of place.
>> These "traceability" issues apply equally to all port allocation
>>methods,
>> right?  Maybe a Privacy Considerations section at the end.
>> I didn't review section 4, because I've reviewed it before.  And I ran
>>out
>> of time.
>> 5. Security Considerations needs a rewrite‹it completely ignores
>>Section 4.
>> That's all I have on this round.
>> Lee
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> sunset4 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sunset4
>>
>
>_______________________________________________
>sunset4 mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sunset4

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.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 25 Sep 2014 05:53:44 -0400

Excellent timing. I've freed myself more or less from some other stuff 
and can get on this today. I get a new version out, then let my 
co-authors address those of Lee's comments that I cannot.

Tom

---

From: Tom Taylor <[email-masked]>
Date: Mon, 29 Sep 2014 11:55:39 -0400

Responses marked with [PTT].

Thanks again for doing this review.

Tom Taylor

On 24/07/2014 4:02 PM, Lee Howard wrote:
> Doing my homework before the WG meeting this afternoon (and re-sending from

[PTT] Done.
>
> Is it worth adding a sentence that these methods are only useful for address
> sharing methods, not NPT, and not encapsulation mechanisms?  It may not be
> necessary.

>
> THat's not an rfc2119 "may not," it's a description of one scenario.  I had
>>     this scenario, there is no concern about port assignment. When NAPT is
>> involved, Š

[PTT] Rewrote and moved text to new paragraph at end of section:

NEW PARA

The considerations in this document do not apply where the CGN does only 
Network Address Translation (NAT) <xref target="RFC3022"/>. In this 
scenario, there is no concern about port assignment. Similarly, this 
document does not apply where encapsulation rather than translation is 
used as the IPv6 transition method.

> independently of the particular flavour should be independent of the

[PTT] I'll leave that to the RFC Editor. According to the grammar I was 
taught, "independently" is an adverb modifying the adjective "applicable".

> NAT44 + Native IPv6 is a perfectly reasonable and likely scenario, so this
> is untrue.  But this whole paragraph reads like a sales pitch for NAT64: cut
> it out.

[PTT] Done.

> [portstudy]. . ."  Though again, this whole study is only true to a point in

[PTT] Changed to "China Mobile". If Gang has a published study he can 
give a reference.
> What incentives?  Does it buy ice cream for everyone who uses IPv6?  Either

[PTT] Done.
> methods.  Clean up that paragraph.

[PTT] This is stateless allocation with embedded IPv4 addresses, so yes, 
when the IPv4 address changes, so does the IPv6 address.
>            user's device is around 200 to 300 ports.  Several devices may
> Avoid the passive voice.  Can you cite the 200-300 number?  Is that true in
> administators may configure 1000 ports.  Or 1001.  Or 999.  Maybe what you
> mean is:
>   1000 ports per subscriber household will provide enough room for multiple
> active users.  Administrators should monitor usage to adjust this number if

[PTT] This comes from the China Mobile study. Here is the new text, 
replacing the existing paragraph from "It has been learned ..." onwards.

NEW

The China Mobile study mentioned earlier observed that the average 
number of sessions consumed by one user's device was around 200 to 300 
ports. Several devices may appear behind a CPE. Based on this 
observation, 1000 ports per subscriber household will provide enough 
room for multiple active users.  Administrators should monitor usage to 
adjust this number if users are being limited by this number, or if 
usage is so low that fewer ports would be sufficient.
> I think you explain this later in the document, but a reference to what you
> mean here would help.

[PTT] Modified text: The assigned ports can be in either a contiguous 
port range or a non-contiguous port range for the sake of defence 
against port-guessing attacks (see <xref target="bulkAlloc_2"/>).

> A+P style [citation needed]
[PTT] RFC 6346.

> that NAT64 is obsolete?  Both in the title and text.

[PTT] Changed to "other".

>     the cautions in [RFC6269 <http://tools.ietf.org/html/rfc6269> ] but does

[PTT] OK, changed "Stepping outside the boundaries" to "Looking beyond". 
The reason to point to DS-Lite is that it does not specify a port 
allocation method. That's the main point.

> <http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#sectio
> n-3>  and Section 4
> <http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#sectio
> n-4>  do not apply
>     to the current work in progress because that work has gone in another
> Do we need to enumerate protocols that this work doesn't apply to?  If so,
> then I think this document is making normative references to those protocols
> (since their port allocation methods could, potentially, change until they
> are published), which will delay publication until lw4over6, MAP-T, MAP-E,

[PTT] Left the summary in, though I don't feel strongly about it.

> 2.4.3 s/alllocation/allocation

[PTT] Ok

> 3.1 US means U.S.?  Americans have higher traffic profiles?

[PTT] Apparently so, subject to the way CableLabs derived their numbers.

> work in greater detail. "

[PTT] OK

> 3.3 Section 11 of RFC6269 refers to fragmentation; you mean section 12.

[PTT] Fixed
   Is
> this section supposed to be a privacy considerations section?

[PTT] Definitely not what we originally had in mind. A separate Privacy 
Considerations section as you suggest may be the way to go, but RFC 6269 
really says it all already..

> Discoverability?  I think in the era of Pervasive Surveillance, reference to

[PTT] Thanks for the 6302 reference.

> appropriate in a document about how to allocate ports in CGN.  A mention of
> it makes sense, but evaluating the capability of different web servers, with

[PTT] Removed summary and appendix.

> These "traceability" issues apply equally to all port allocation methods,

> I didn't review section 4, because I've reviewed it before.  And I ran out
> of time.
> 5. Security Considerations needs a rewrite‹it completely ignores Section 4.

[PTT] Section 4 is gone now, based on feedback from Toronto.

> That's all I have on this round.
Thanks again.
Tom