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

From: Lee Howard <[email-masked]>
Date: Thu, 24 Jul 2014 16:02:40 -0400

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#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
   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

---

From: "George, Wes" <[email-masked]>
Date: Mon, 28 Jul 2014 09:42:11 -0400

Additional comments:

Chair:
As noted during the meeting, if the deterministic CGN section is to stay in this document (we'll call consensus on that separately as a part of WG adoption call), the IPR statement from
https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-donley-behave-deterministic-cgn will need to be updated to point to this document instead.

Individual:
2.4.1 - worth noting that log size may be governed by legal and company policy regarding the length of time a given set of logs must be retained, months vs years, and that while a fairly large log with a short storage duration might be manageable, a large log coupled with a long duration retention requirement may become prohibitively expensive, even with compression and archiving to cheaper long-term storage media.
Table 1 - need to specify that this is RAW (uncompressed) log size

Failover considerations shouldn't be specific to deterministic port alloc, maybe promote to a main section and expand, or duplicate for section 3, add to section 3.4, etc. Basically, with each port allocation method you discuss, you need to cover failover considerations. This is especially important if state is maintained and must be synced between a primary and backup, or if it operates in active/active mode with load balancing, etc.

Need to update section 4.4 with more up-to-date info on IPv6 penetration on Alexa top 1M (a lot has changed since 2012), probably including a reference to the source for that information so that the reader can follow it to get more up-to-date information.

Thanks,

Wes

From: Lee Howard <[email-masked]<mailto:[email-masked]>>
Date: Thursday, July 24, 2014 at 4:02 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [sunset4] review of draft-chen-sunset4-cgn-port-allocation

Doing my homework before the WG meeting this afternoon (and re-sending from the correct email address). . .

1. Introduction
You say:

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, …

independently of the particular flavour should be independent of the particular flavour

Also,

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:

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).

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.

This is a good point.

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.

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.

I think you explain this later in the document, but a reference to what you mean here would help.

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?

The proposals made in Section 3<http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#section-3> and Section 4<http://tools.ietf.org/html/draft-chen-sunset4-cgn-port-allocation-04#section-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.

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.

Lee

________________________________
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.