Subject: Re: [sunset4] WG Adoption call for draft-chen-sunset4-nat64-port-allocation

From: JF Tremblay <[email-masked]>
Date: Fri, 1 May 2015 16:36:42 -0400

> On Apr 21, 2015, at 1:46 PM, George, Wes <[email-masked]> wrote:
> 
> This will start the two week adoption call for draft-chen-sunset4-nat64-port-allocation. This is the draft that previously was known as draft-chen-sunset4-cng-port-allocation but was renamed once the IPR-encumbered text was removed. 
> 
> http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/ <http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/>
> 
> Please send support for adoption to the list, as well as any comments to improve the draft. This is a current charter milestone for the WG.

I’ve found the information presented in this document to be useful for deployers of NAT64s and support its adoption. 

My general feeling of the document, however, is that many topics are described very verbosely, sometimes in a confusing manner. It would be great to use more to-the-point language and descriptions. Having a clear and focused document on port {block,range} allocations techniques, sizes and pitfalls would help the reader. Describing the vocabulary, design goals and tradeoffs would also be useful. 

I had the following comments regarding the content: 

2.2.2 "Preassigned port ranges occupy memory even when there are unused ports."
Really? A range with two port numbers is negligible quantity compared to a five-tuple or other data. 

2.4.1 "The storage of log information may pose a challenge to operators, since it requires additional resources and data inspection processes to identify users."
The data inspection remark here does not make sense. The NAT might correlate source addresses to user information if it has it available, but it won’t inspect. The NAT does not store either. 

2.4.1 In the result table, the dynamic port-range allocation is dependant of the range size and timing, that should be mentioned. (what values where used to get to this result?) 

2.4.2: "The user's behavior normally correlates with system performance.”
Did you mean s/behavior/experience/ ? Otherwise I can’t grok this. Even with that change, I’m sure if this sentence is useful. 

2.4.2: I’m not sure the reference to RFC6191 makes that much sense. RFC6191 describes host behavior for incoming connections, while the goal here is to safely optimize re-use of outgoing NAT ports. 
As a side note, it might be useful to discuss the merits and problems relating to TIME-WAIT assassination here. 

2.4.3: Why not cover port block randomization here as well? 

3.2 The whole section about block timers is quite hard to follow. A block may have an additional timer applied after all ports are free. Having a clear definition here would help more than discussions around it. 

3.2 6th paragraph suggests a very dangerous idea, that is to re-use ports in the latest block as soon as possible. This has the potential of bringing problems with rapid port re-use in blocks with very few available ports. This also slows down block re-allocation and reduces port usage overall, because of the typical port usage patterns (which is spiky in nature rather than linear). 

3.3 The recommendations on source port logging are superfluous in this document. RFC6302 is well enough imo. 

Things I didn’t see in this document that an implementer may be looking for: 
- Port allocation design goals. 
- Clear definitions of port range allocation terms (including timers)
- Address stickiness concept definition
- Possible ratios of users per address and tradeoffs. 
- The idea of a refresh log (in addition to start-end logs, for long-lived blocks)
- Discussion on logging stability, timestamping, reliability.   
- Discussion on port usage patterns and re-usage algorithms 

JF

---

From: GangChen <[email-masked]>
Date: Sun, 3 May 2015 21:36:01 +0800

Thank you for the comments. I'd seen it's great useful to improve the
draft quality.
Please see my reply inline.

2015-05-02 4:36 GMT+08:00, JF Tremblay <[email-masked]>:
>> This will start the two week adoption call for
>> draft-chen-sunset4-nat64-port-allocation. This is the draft that
>> previously was known as draft-chen-sunset4-cng-port-allocation but was
>> renamed once the IPR-encumbered text was removed.
>>
>> http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/
>> <http://datatracker.ietf.org/doc/draft-chen-sunset4-nat64-port-allocation/>
>>
>> Please send support for adoption to the list, as well as any comments to
>> improve the draft. This is a current charter milestone for the WG.
>
>
> I’ve found the information presented in this document to be useful for
> deployers of NAT64s and support its adoption.
>
> My general feeling of the document, however, is that many topics are
> described very verbosely, sometimes in a confusing manner. It would be great
> to use more to-the-point language and descriptions. Having a clear and
> focused document on port {block,range} allocations techniques, sizes and
> pitfalls would help the reader. Describing the vocabulary, design goals and
> tradeoffs would also be useful.

Great. You just hit the point.
That is also my thinking how to improve the draft description.

> five-tuple or other data.

I guess it may not only port information matter. One implementation I
can see is it will also create mapping table when it reserves a port
range.

> 2.4.1 "The storage of log information may pose a challenge to operators,
> since it requires additional resources and data inspection processes to
> identify users."
> The data inspection remark here does not make sense. The NAT might correlate
> source addresses to user information if it has it available, but it won’t
> inspect. The NAT does not store either.

the issue is a NAT may don't know what source address should be correlated.
Therefore, the NAT have to store entire information preparing the searching.
For your information, the NAT should store at least three-months log
in our networks.

> 2.4.1 In the result table, the dynamic port-range allocation is dependant of
> the range size and timing, that should be mentioned. (what values where used
> to get to this result?)

great. I will add in the next version.

> Did you mean s/behavior/experience/ ? Otherwise I can’t grok this. Even with
> that change, I’m sure if this sentence is useful.

The sentence is not useful. I like the proposal that just directly
going to the point . I will change the description.

> 2.4.2: I’m not sure the reference to RFC6191 makes that much sense. RFC6191
> describes host behavior for incoming connections, while the goal here is to
> safely optimize re-use of outgoing NAT ports.
> As a side note, it might be useful to discuss the merits and problems
> relating to TIME-WAIT assassination here.

Got your point. It will be clear.

> 2.4.3: Why not cover port block randomization here as well?

Good to know more if you point me a reference of "port block randomization".

> 3.2 The whole section about block timers is quite hard to follow. A block
> may have an additional timer applied after all ports are free. Having a
> clear definition here would help more than discussions around it.
>
> 3.2 6th paragraph suggests a very dangerous idea, that is to re-use ports in
> the latest block as soon as possible. This has the potential of bringing
> problems with rapid port re-use in blocks with very few available ports.
> This also slows down block re-allocation and reduces port usage overall,
> because of the typical port usage patterns (which is spiky in nature rather
> than linear).
>

Those three questions I would leave to my co-authors for more feedback.
> - Discussion on port usage patterns and re-usage algorithms

That is a good suggestion. Those information may implicitly described
in the document.
Again, I agree you general comments of " to-the-point language and
descriptions."
It hopefully will be clear when we improve the description.

Best Regards

Gang

---

From: JF Tremblay <[email-masked]>
Date: Mon, 4 May 2015 10:29:39 -0400

Inline. 

> On May 3, 2015, at 9:36 AM, GangChen <[email-masked]> wrote:
> 

In my opinion: 
- NATs do not / should not store logs. This is done by an external server (syslog or other).
- NATs do not correlate source addresses to users, unless it already has that information available. This can be done offline by a server with much more ressources. 

This could be guidance to put in this document, if not mentioned elsewhere. (but I thought that was quite obvious)

> Good to know more if you point me a reference of "port block randomization”.

There isn’t a reference. I might have coined the term a couple of years back, not sure. This is basically the act of randomizing the assignments of blocks instead or in conjunction with port randomization within the block.  
This could be a concept defined and discussed in this document. 

/JF

---

From: "Huangjing (A)" <[email-masked]>
Date: Tue, 5 May 2015 07:11:03 +0000

Hi, JF,

See inline

James

> -----Original Message-----
> From: sunset4 [mailto:[email-masked]] On Behalf Of JF Tremblay
> Sent: Monday, May 04, 2015 10:30 PM
> To: GangChen
> Cc: [email-masked]
> Subject: Re: [sunset4] WG Adoption call for
> draft-chen-sunset4-nat64-port-allocation
> 
> Inline.
> 
> >> 2.4.1 "The storage of log information may pose a challenge to
> >> operators, since it requires additional resources and data inspection
> >> processes to identify users."
> >> The data inspection remark here does not make sense. The NAT might
> >> correlate source addresses to user information if it has it
> >> available, but it won’t inspect. The NAT does not store either.
> >
> - NATs do not correlate source addresses to users, unless it already has that
> information available. This can be done offline by a server with much more
> ressources.

Agree, log processing is out of the scope of NAT.

> There isn’t a reference. I might have coined the term a couple of years back,
> not sure. This is basically the act of randomizing the assignments of blocks
> instead or in conjunction with port randomization within the block.

I think you are talking about the port block randomization algorithms similar to those defined in RFC6431.
Will add some analysis and reference

> 
> /JF
> 
> 
> 
> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4

---

From: JF Tremblay <[email-masked]>
Date: Tue, 5 May 2015 08:11:05 -0400

> On May 5, 2015, at 3:11 AM, Huangjing (A) <[email-masked]> wrote:
> 
>>> 

Thanks for the reference, James. Interesting. I had in mind a non-cryptographically random set of port, which doesn’t seem to be handled in RFC6431. That would basically be a continuous set of ports where the first port is assigned randomly or semi-randomly (could be on block boundary for example). This concept could be defined and discussed in this document, but it’s just a minor point for discussion/improvement. 

JF

---

From: "Mukom Akong T." <[email-masked]>
Date: Sun, 10 May 2015 22:04:07 +0400

I've read it and support adoption as well. I also agree with JF's point
that the NAT doesn't do logging and inspection. While that is an important
consideration deployment, I think section 2.4.1 should explicitly state
that such logging and inspection are done on another system, not the NAT64
one.

Regards

On Tue, May 5, 2015 at 4:11 PM, JF Tremblay <
[email-masked]> wrote:

> Thanks for the reference, James. Interesting. I had in mind a
> non-cryptographically random set of port, which doesn’t seem to be handled
> in RFC6431. That would basically be a continuous set of ports where the
> first port is assigned randomly or semi-randomly (could be on block
> boundary for example). This concept could be defined and discussed in this
> document, but it’s just a minor point for discussion/improvement.
>
> JF
>
>
>

-- 

Mukom Akong T.

http://about.me/perfexcellence |  twitter: @perfexcellent
------------------------------------------------------------------------------------------------------------------------------------------
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
-------------------------------------------------------------------------------------------------------------------------------------------

---

From: GangChen <[email-masked]>
Date: Mon, 11 May 2015 10:57:12 +0800

Hello Mukom and JF,

Thank you for the review and support.
The point of NAT logging is well understood.
We will explicitly state that in the next version.

Best Regards

Gang

2015-05-11 2:04 GMT+08:00, Mukom Akong T. <[email-masked]>:
>> >> There isn’t a reference. I might have coined the term a couple of
>> >> years
>> back,

---

From: "George, Wes" <[email-masked]>
Date: Mon, 11 May 2015 11:07:08 -0400

We have seen no opposition to adopting this document as a WG document. Authors, when you have a version ready that incorporates the recent feedback, please post it as as draft-ietf-sunset4-nat64-port-allocation

Thanks,

Wes

From: <George>, "George, Wes" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 21, 2015 at 1:46 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: WG Adoption call for draft-chen-sunset4-nat64-port-allocation

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
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: "Huangjing (A)" <[email-masked]>
Date: Tue, 19 May 2015 02:20:04 +0000

Hi, JF,

Thanks for the information!

James

> From: JF Tremblay [mailto:[email-masked]]
> Sent: Tuesday, May 05, 2015 8:11 PM
> To: Huangjing (A)
> Cc: [email-masked]; GangChen; Tom Taylor
> >> years back, not sure. This is basically the act of randomizing the
> >> assignments of blocks instead or in conjunction with port randomization
> within the block.
> non-cryptographically random set of port, which doesn’t seem to be handled in
> RFC6431. That would basically be a continuous set of ports where the first port
> is assigned randomly or semi-randomly (could be on block boundary for
> example). This concept could be defined and discussed in this document, but
> it’s just a minor point for discussion/improvement.
> 
> JF
> 
>