Subject: [BEHAVE] LSN: bulk ports

From: "Dan Wing" <[email-masked]>
Date: Tue, 8 Feb 2011 12:06:44 -0800

Regarding Section 7.2 of draft-ietf-behave-lsn-requirements-00:

  "7.2. Fixed port assignment

   To save costs for storage, one can adopt this port assignment
   mechanism at LSN.  By fixing the range of external port per
   user/CPE, and having the mapping of internal IP address to external
   IP address and port, there will be no need to store per session
   log.  Note that this mechanism is possible only if the source port
   is known as well as the source address, the destination address and
   the destination port."

The text in the I-D needs more detail.

There is a range of things a CGN can do:

   1. for every outgoing connection, create one mapping.
   2. for an outgoing connection, create a "bin" of several mappings
      using random public ports.  Subsequent outgoing connections will
      use ports from the "bin".  When the "bin" is full, a new
      connection causes a new bin to be created.  A bin is smaller or
      equal to the user's maximum port limit.
   3. Same as (2), but the ports allocated to a "bin" are consecutive
      public ports.

I have seen both (2) and (3) described as "bulk port allocation".  But 
they are different.

With the above three design (or configuration) decisions, there are at 
least four axis to consider:  port utilization scaling, logging scaling
(which is the subject of draft-ietf-behave-lsn-requirements-00's
Section 7.2), security, and port re-use.  All three should be discussed 
in a subsequent version of draft-ietf-behave-lsn-requirements:

* Port Utilization Scaling:  The mechanisms at the top of the list are
  very efficient in their port utilization.  In that sense, they have
  good scaling properties (nothing is wasted).  The mechanisms at the
  bottom of the list will waste ports.  The number of wasted ports is
  proportional to size of the "bin".

* Logging Scaling:  Mechanism (1) logs destinations.  Mechanisms (2)
  and (3) log only the source port.  Mechanism (2) creates a slightly
  larger log (listing all of the port numbers) whereas (3) could
  indicate a range (e.g., "12000-12009") that is quite compact.

  Mechanism (1) creates a lot of log entries.  Mechanism (2) and
  (3) create the same number of log entries, but (3)'s log entries are
  smaller because a range can be expressed very compactly.  With large 
  "bin" sizes, the logging for mechanisms (2) and (3) can approach 
  the logging frequency of DHCP servers.

  However, mechanism (2) and (3) REQUIRE SERVERS ON THE INTERNET TO
  LOG SOURCE PORTS.  If we suggest that CGN's do any sort of bulk port
  allocation (2) or (3), it is important to discuss the need for
  content servers to implement
  draft-ietf-intarea-server-logging-recommendations.  By content
  servers, this means any server that might ask (or demand) the ISP
  disclose the identity of a subscriber that made a certain connection
  to a server running HTTP, HTTPS, ssh, IMAP, IMAPS, SMTP, etc.

* Security: Mechanisms (1) and (2) provide very good security in that
  ports numbers are not easily guessed.  Easily guessed port numbers
  put subscribers at risk of the attacks described in RFC6056 (it
  cites RFC5927, RFC4953, and Paul Watson's "Slipping in the Window:
  TCP Reset Attacks").  Mechanism (3) provides poor security to
  subscribers, especially if the "bin" size is large.

* Port Re-Use:  It should also be discussed in the CGN Requirements
  document if a CGNis allowed or prohibited from re-using a port that
  was previously assigned to the same internal host.  For example, if
  an internal host is mapped to a certain port and then finishes using
  that port (e.g., with a proper FIN/FINACK/ACK handshake, TCP RST, or
  it simply times out due to inactivity), and after that port's
  TIME_WAIT-like delay has expired, can the NAT re-use the port for a
  new connection.  This decision has impacts on port utilization
  scaling, logging scaling, and security.

-d

---

From: Shin Miyakawa <[email-masked]>
Date: Fri, 25 Feb 2011 15:54:36 +0900 (JST)

Dear BEHAVE Chairs,

We lsn-requirement draft authers have discussed and
(1)We're welcome the new editor as you suggested.
(2)We'd like to update our drafts to follow the comments especially Chairs'.
However so, still some points are not settled down. For example;

Dan said ;

  From: "Dan Wing" <[email-masked]>
  Subject: LSN: bulk ports
  Date: Tue, 8 Feb 2011 12:06:44 -0800
  Regarding Section 7.2 of draft-ietf-behave-lsn-requirements-00:
  <snip>
  The text in the I-D needs more detail.
  <snip>

However so, in the different mail from Dave, another BEHAVE Chair wrote :

  From: Dave Thaler <[email-masked]>
  Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-lsn-requirements-00.txt
  Date: Sun, 7 Nov 2010 02:36:59 +0000

  8) Section 7 starts to describe a mechanism ("The following mechanisms can be used ..."). 
  I don't think that's appropriate in a requirements document.   
  Sections 7.1 and 7.2 should be deleted in my view. 

So we're very confused. At least, talking about the section 7.2 of our drafts,

  Should we add more detail (Dan's suggestion) ?

or, 

  Should we delete it (Dave's suggestion) ?

Chairs, 
please make us know the way we should go. (Psalm 143:8)

# Or can we discussed this a bit off mailing list first ?

Best wishes,

Shin Miyakawa