Subject: [BEHAVE] [CGN reqs] Adjustments to logging section

From: Simon Perreault <[email-masked]>
Date: Fri, 05 Aug 2011 08:13:52 -0400

All,

I received a request to adjust the logging section text as follows.
Unless the WG disagrees, this will be in the next revision. Please note
that this section is still informative (non normative).

OLD:
   Logging:  Traditional allocation creates a lot of log entries.
      Allocation by random or consecutive port sets create the same
      number of log entries, but the entries in the case of consecutive
      port sets are smaller because the sets can be expressed very
      compactly by indicating a range (e.g. "12000-12009").

NEW:
   Logging:  Traditional allocation creates a lot of log entries,
      whereas allocation by port sets create much fewer entries.  Random
      and consecutive port sets generate the same number of log entries,
      but the entries in the case of consecutive port sets are smaller
      because the sets can be expressed very compactly by indicating a
      range (e.g. "12000-12009").  Note also that some random port set
      allocation schemes generate small log entries containing the
      parameters and algorithm used for the port set generation (see
      e.g.  [I-D.boucadair-pppext-portrange-option]).

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 5 Aug 2011 16:27:39 -0400

On 8/5/11 5:13 AM, "Simon Perreault" <[email-masked]> wrote:

>       whereas allocation by port sets create much fewer entries.

Suggestion

"Traditional allocation creates a lot of log entries as compared to
allocation by port sets which create much fewer entries."

Reasoning is that 'creates a lot of log entries' is subjective.

>  Random

---

From: Dave Thaler <[email-masked]>
Date: Fri, 5 Aug 2011 21:14:17 +0000

The third new sentence (which is correct) contradicts the 2nd
new sentence which needs to be updated to account for that.

-Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Friday, August 05, 2011 5:14 AM
To: [email-masked]
Subject: [BEHAVE] [CGN reqs] Adjustments to logging section

All,

I received a request to adjust the logging section text as follows.
Unless the WG disagrees, this will be in the next revision. Please note that this section is still informative (non normative).

OLD:

NEW:

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 5 Aug 2011 17:31:21 -0700

>       e.g.  [I-D.boucadair-pppext-portrange-option]).

Much of the logging savings attributed to bulk port schemes is because
the destination isn't logged.  To avoid identifying too many subscribers,
this relies on the servers logging the source port.  So, Section 5 
should add something like:

  Some of the log reduction of bulk port allocation is because the
  destination is not logged.  As with random port allocation (Section 4),
  if the destination is not logged the servers need to log the
  source port [RFC6302].  If the servers do not log the source port,
  it is impossible to distinguish between users of that same IP address
  accessing that server.

You might consider generalizing this a bit more and creating a small
section titled something like "User Identification if Destination Is 
Not Logged", and providing forward references from Section 4 and Section 
5 to that new section -- as it applies equally to both.

-d

---

From: Simon Perreault <[email-masked]>
Date: Fri, 05 Aug 2011 21:19:15 -0400

Le 05/08/2011 8:31 PM, Dan Wing a écrit :
> the destination isn't logged.

I'm not following you. It's also possible to not log the destination 
with the traditional port allocation scheme, and bulk port allocation 
would still generate much fewer log entries. So I don't see how your 
proposed text is accurate.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 5 Aug 2011 18:35:13 -0700

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Friday, August 05, 2011 6:19 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [BEHAVE] [CGN reqs] Adjustments to logging section
> 

What you say is true.  But I have never hard of anyone considering 
bulk (source) port allocation combined with destination logging --
there's no logging-related purpose (although there may well be 
other purposes, but none of which have come up on the mailing list).

-d

---

From: Simon Perreault <[email-masked]>
Date: Sat, 06 Aug 2011 09:08:52 -0400

> other purposes, but none of which have come up on the mailing list).

Well, we're not talking exclusively about destination logging. We're 
talking about logging in general. Bulk port allocation generates fewer 
log entries, but you do need to use traditional allocation if you need 
destination logging. There's already a paragraph exclusively about this 
in the doc:

       Traditional allocation can log destinations while random and
       consecutive port sets cannot.  This means that a CGN implementing
       one of the latter two will rely on the remote peer to follow the
       recommendations in
       [I-D.ietf-intarea-server-logging-recommendations].  If this is not
       acceptable, random or consecutive port sets cannot be used.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 11 Aug 2011 09:21:57 -0400

On 2011-08-11 03:24, Rémi Després wrote:
> If the algorithm used for port-set generation is stateless, as
> proposed with 4rd, log entries don't need to contain "parameters and
> algorithm used for the port set generation".

I understand your point, but stateless solutions such as 4rd are out of
scope for this document. We're talking about CGN logging. There really
is no CGN in 4rd. Just a layer 4 router. And as I understand it, 4rd
allocations could be logged directly by the DHCP server.

Simon