Subject: [BEHAVE] CGN REQ: Port Set Assignment

From: <[email-masked]>
Date: Tue, 15 Mar 2011 16:07:16 +0100

Re-,

Section 5 http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-01#section-5 discusses various modes for the port assignment but there is no explicit requirement.

I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) support the ability to assign port sets. The selection of the dynamic mode vs. port set is deployment-specific.

Cheers,
Med

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 10:55:39 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Tuesday, March 15, 2011 8:07 AM
> To: [email-masked]
> Cc: 'behave' <([email-masked])>
> Subject: [BEHAVE] CGN REQ: Port Set Assignment
> 
> Re-,
> 
> Section 5 http://tools.ietf.org/html/draft-ietf-behave-lsn-
> requirements-01#section-5 discusses various modes for the port
> assignment but there is no explicit requirement.
> 
> I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?)
> support the ability to assign port sets.

Why?

-d

> The selection of the dynamic
> mode vs. port set is deployment-specific.
> 
> Cheers,
> Med

---

From: <[email-masked]>
Date: Tue, 15 Mar 2011 19:18:51 +0100

Re-,

Please see inline.

Cheers,
Med
________________________________________
De : Dan Wing [[email-masked]]
Date d'envoi : mardi 15 mars 2011 18:55
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment

Why?

Med: We can ask the other question around: why only the dynamic NAT should be supported?
More seriously, the use of port set has several advantages in term of log reduction and in some implementation(s) has important  impact on performances (because of the per-entry write operations). Tests we have done for some implementations showed severe degradation. FWIW, some CGN implementations support only the port set allocation and the length of the port set is even no configurable! 

IMO, the decision to activate the port set or use the dynamic mode should left to operators (enterprise, service providers, etc.).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 11:51:28 -0700

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, March 15, 2011 11:19 AM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]
> Subject: RE : [BEHAVE] CGN REQ: Port Set Assignment
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med

Because that's what NATs do today -- NATs in people's homes and
deployed by enterprises do that today.

> More seriously, the use of port set has several advantages in term of
> log reduction and in some implementation(s) has important  impact on
> performances (because of the per-entry write operations). Tests we have
> done for some implementations showed severe degradation. FWIW, some CGN
> implementations support only the port set allocation and the length of
> the port set is even no configurable!

Yes, well aware.

> IMO, the decision to activate the port set or use the dynamic mode
> should left to operators (enterprise, service providers, etc.).

Their incentive is to reduce costs.  But "port sets" (or "bulk port
allocations", or whatever term) increase the attack surface of
the subscribers, with no cost or security risk to the ISP.  The
incentives are in the wrong place.  It's obvious what an ISP
will do -- they will prefer to increase the attack surface of
their subscribers.

Speaking personally (not as chair), I do not support the 
IETF making a recommendation that users be restricted to
a fixed set of port numbers.

-d

---

From: <[email-masked]>
Date: Tue, 15 Mar 2011 20:02:23 +0100

Re-

A "Port Set" does not mean necessarily "contiguous port range"!

Both pure randomized port set or Simple port randomization with port sets can be considered.

We have an implementation to assess the behavior of simple port randomization (only two lines of codes are needed to implement it: the algorithm uses the port mask and port value).

Another solution to generate random ports is available at: http://tools.ietf.org/html/draft-bajko-pripaddrassign-03#section-5.

Cheers,
Med

Date d'envoi : mardi 15 mars 2011 19:51

Yes, well aware.

-d

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 15 Mar 2011 14:31:18 -0500

On 3/15/11 9:07 AM, "[email-masked]"
<[email-masked]> wrote:

> Section 5 
> http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-01#section-5
> discusses various modes for the port assignment but there is no explicit
> requirement. 
>  
> I suggest in addition to the dynamic mode, the CGN MUST (SHOULD?) support the
> ability to assign port sets. The selection of the dynamic mode vs. port set is
> deployment-specific.

I don't support this as a MUST or SHOULD.  A port-set feature isn't a
requirement for successful deployment of a CGN.  In fact, a port-set feature
might be seen to have negative implications for security, scale, etc.  It is
an implementation choice, and the requirements document ought to capture it
as a MAY.

Cheers,
-Benson

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 14:28:28 -0700

> Sent: Tuesday, March 15, 2011 12:02 PM
> Cc: [email-masked]; DENG Xiaohong ESP/PEK

It is not relevant if they are contiguous or not.  This is a false sense of
security.

If they are fixed, the ports can be determined by causing the victim to view
HTML which opens img1.example.com, img2.example.com, img3.example.com, etc.,
to servers controlled by the attacker.  The attacker can then have
Javascript release one of those mappings, wait, and the  attacker will know
the victim will re-use that port -- because it's the only port available.
Proof of concept code that does this has been circulating.

-d

> We have an implementation to assess the behavior of simple port
> randomization (only two lines of codes are needed to implement it: the
> algorithm uses the port mask and port value).
> 
> Another solution to generate random ports is available at:
> http://tools.ietf.org/html/draft-bajko-pripaddrassign-03#section-5.
> 
> Cheers,
> Med
> 
>

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Mar 2011 18:18:47 -0400

That are security considerations that need to be understood in relation to
port block. But many of those can be mitigated. Having said that, I would
guess there are at least 3 CGN vendors that implement such a feature.
Therefore, CGN vendors already do that today.

As for your example, If the attacker has this access to your machine the
victim should be worried about his credit card, not ports. (;-)

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 15:33:37 -0700

> Behalf Of Reinaldo Penno
> Sent: Tuesday, March 15, 2011 3:19 PM
> To: Dan Wing; [email-masked]; draft-ietf-behave-
> [email-masked]
> Cc: 'DENG Xiaohong ESP/PEK'; [email-masked]
> Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment
> 
> As for your example, If the attacker has this access to your machine
> the victim should be worried about his credit card, not ports. (;-)

Yes, there are always more severe risks.  Could get run over by a bus, too.

But building a system which has predictable ports is risky for two reasons:

  * security, which everyone likes to discount as "not important".
  * the port limit will be wrong
      o It will be either too high (too many ports, costing money 
        in the future ("why are we spending $30 for each IPv4 
        address, giving everyone 1000 ports, but the average user
        only consuming 10 ports?  We are throwing money away"), 
      o It will be too low (too few ports, harming an application,
        causing support calls).  This will be expensive to correct,
        with some fixed-port schemes, because it requires re-IP'ing
        the access network for some users or for all users.  Some
        other fixed-port schemes could be changed with a single
        CLI setting, and don't have this risk.

-d

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

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 15 Mar 2011 18:51:57 -0400

>   * the port limit will be wrong

There are many ways to overcome the issues you point below. I think you
might have a specific implementation in mind.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 15:59:16 -0700

> Sent: Tuesday, March 15, 2011 3:52 PM
> >> That are security considerations that need to be understood in
> relation
> >> to

I am thinking of A+P-like schemes.  No implementation magic can
change the number of ports allocated by those schemes, because
those schemes generally stick port information into the IPv6
address or into a tunnel header.

-d

> >>> If they are fixed, the ports can be determined by causing the
> victim
> >> to view

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 07:16:42 +0100

Dear Benson,

The port set does not means contiguous port range. Random port set can be handled by the CGN. This should be explicit in the requirements IMO.

In deployments where a small address sharing ration is needed (e.g., 1:2, 1:3), port randomization is still possible within the large port range.

The I-D already discusses the trade-offs:

   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].
      Mechanism (3) provides poor security to subscribers, especially if
      the "bin" size is small.

Cheers,
Med 

-----Message d'origine-----
De : Benson Schliesser [mailto:[email-masked]] 
Envoyé : mardi 15 mars 2011 20:31
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : 'behave' <([email-masked])>
Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment

Cheers,
-Benson

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 07:21:09 +0100

Hi Dan,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 15 mars 2011 22:28
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : [email-masked]; DENG Xiaohong ESP/PEK
Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment

Med: Your point is valid. This is why there are other mode for the assignment of the port sets: when a packet arrives and now binding is available, a small random port set is generated. Once all the ports are used, a new random port set is generated, etc. This processes is repeated until reaching the per-subscriber quota. A user is never assigned the same port sets. The size of the port set per binding is configurable.

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 07:27:52 +0100

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 15 mars 2011 23:59
À : 'Reinaldo Penno'; BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : DENG Xiaohong ESP/PEK; [email-masked]
Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment

> might have a specific implementation in mind.

I am thinking of A+P-like schemes. 

Med: Which ones? Dynamic modes have been proposed in A+P; see http://tools.ietf.org/html/draft-rqb-dynamic-port-ranges-02. Port randomization requirement can be fairly honored.

 No implementation magic can
change the number of ports allocated by those schemes, because
those schemes generally stick port information into the IPv6
address or into a tunnel header.

Med: This is true for the stateless A+P mode but not the binding mode (see: http://tools.ietf.org/html/draft-ymbk-aplusp-09#section-4.4 for more details).

-d

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 18:10:31 +0800

|> >> -----Original Message-----
|> >> From: [email-masked] [mailto:[email-masked]] On 
|> >> Behalf Of Reinaldo Penno
|> >> Sent: Tuesday, March 15, 2011 3:19 PM
|> >> To: Dan Wing; [email-masked]; draft-ietf-
|> behave-
|> >> [email-masked]
|> >> Cc: 'DENG Xiaohong ESP/PEK'; [email-masked]
|> >> Subject: Re: [BEHAVE] CGN REQ: Port Set Assignment
|> >>
|> >> That are security considerations that need to be understood in
|> relation
|> >> to
|> >> port block. But many of those can be mitigated. Having 
|said that, I 
|> >> would guess there are at least 3 CGN vendors that implement such a
|> feature.
|> >> Therefore, CGN vendors already do that today.
|> >>
|> >> As for your example, If the attacker has this access to your 
|> >> machine the victim should be worried about his credit card, not 
|> >> ports. (;-)
|> >
|> > Yes, there are always more severe risks.  Could get run over by a
|> bus, too.
|> >
|> > But building a system which has predictable ports is risky for two
|> reasons:
|> >
|> >   * security, which everyone likes to discount as "not important".
|> >   * the port limit will be wrong
|> 
|> There are many ways to overcome the issues you point below. I think 
|> you might have a specific implementation in mind.
|
|I am thinking of A+P-like schemes. 

Xiaohong: When you refer to A+P-like schemes, I can imagine B4 element
 with port set restricted NAT and AFTR with by passing port set feature,
and 
Address + Port embedded IPv6 prefix is not necessary for Port Set
Assignment.
 Does that make sense?

|
|Med: Which ones? Dynamic modes have been proposed in A+P; see 
|http://tools.ietf.org/html/draft-rqb-dynamic-port-ranges-02. 
|Port randomization requirement can be fairly honored.
|
| No implementation magic can
|change the number of ports allocated by those schemes, because 
|those schemes generally stick port information into the IPv6 
|address or into a tunnel header.
|
|Med: This is true for the stateless A+P mode but not the 
|binding mode (see: 
|http://tools.ietf.org/html/draft-ymbk-aplusp-09#section-4.4 
|for more details).

Xiaohong: Right, the binding mode doesn't require  stick port
information into
 the IPv6  address or into a tunnel header.

Cheers,
Xiaohong
opensource A+P: http://opensourceaplusp.weebly.com/

|
|
|
|-d
|
|
|> >       o It will be either too high (too many ports, costing money
|> >         in the future ("why are we spending $30 for each IPv4
|> >         address, giving everyone 1000 ports, but the average user
|> >         only consuming 10 ports?  We are throwing money away"),
|> >       o It will be too low (too few ports, harming an application,
|> >         causing support calls).  This will be expensive to correct,
|> >         with some fixed-port schemes, because it requires re-IP'ing
|> >         the access network for some users or for all users.  Some
|> >         other fixed-port schemes could be changed with a single
|> >         CLI setting, and don't have this risk.
|> >
|> > -d
|> >
|> >
|> >>
|> >> On 3/15/11 2:28 PM, "Dan Wing" <[email-masked]> wrote:
|> >>
|> >>>> A "Port Set" does not mean necessarily "contiguous port range"!
|> >>>
|> >>> It is not relevant if they are contiguous or not.  This 
|is a false
|> >> sense of
|> >>> security.
|> >>>
|> >>> If they are fixed, the ports can be determined by causing the
|> victim
|> >> to view
|> >>> HTML which opens img1.example.com, img2.example.com,
|> >> img3.example.com, etc.,
|> >>> to servers controlled by the attacker.  The attacker can 
|then have 
|> >>> Javascript release one of those mappings, wait, and the  attacker
|> >> will know
|> >>> the victim will re-use that port -- because it's the only port
|> >> available.
|> >>> Proof of concept code that does this has been circulating.
|> >>
|> >> _______________________________________________
|> >> Behave mailing list
|> >> [email-masked]
|> >> https://www.ietf.org/mailman/listinfo/behave
|> >
|> 
|> _______________________________________________
|> Behave mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/behave
|
|

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 10:19:39 -0400

On 2011-03-16 02:21, [email-masked] wrote:
> If they are fixed, the ports can be determined by causing the victim
> to view HTML which opens img1.example.com, img2.example.com,
> img3.example.com, etc., to servers controlled by the attacker.  The
> attacker can then have Javascript release one of those mappings,
> wait, and the  attacker will know the victim will re-use that port --
> because it's the only port available. Proof of concept code that does
> this has been circulating.
> 
> Med: Your point is valid. This is why there are other mode for the
> assignment of the port sets: when a packet arrives and now binding is
> available, a small random port set is generated. Once all the ports
> are used, a new random port set is generated, etc. This processes is
> repeated until reaching the per-subscriber quota. A user is never
> assigned the same port sets. The size of the port set per binding is
> configurable.

I fail to see how this prevents the attack Dan described. Are the ports
within a port set only used once? If so, it will come with heavy impacts
on port utilization.

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: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 10:21:59 -0400

>       Mechanism (3) provides poor security to subscribers, especially if

I think it will need to be changed in light of the attack described by
Dan. To me, (2) does not appear to be as secure as (1) anymore.

Simon

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 15:31:52 +0100

In your previous mail you wrote:

   Random port set can be handled by the CGN.
   
=> I have a concern about the term 'random set' because I am not sure
about its meaning (so if I missed the definition please send the
pointer to me).

Regards

[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Mar 2011 10:34:57 -0400

> about its meaning (so if I missed the definition please send the

Useful to all: it corresponds to mechanism (2) in section 5.

Simon

---

From: <[email-masked]>
Date: Wed, 16 Mar 2011 15:37:48 +0100

Hi Francis,

By "random port set", I meant:

* a set of ports which are randomly generated when a new outbound packet is received by the CGN
* the port set is not contiguous
* the port set is not fixe
* for subsequent packet requiring a new port, a port from the pre-allocated random port set is used
* when all the ports in the port set are in-use, a new random port set is generated by the CGN, etc until reaching a quota.

We can find a better name for this.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mercredi 16 mars 2011 15:32
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Benson Schliesser; [email-masked]; 'behave' <([email-masked])>
Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment 

   

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 08:05:51 -0700

> Sent: Tuesday, March 15, 2011 11:28 PM
> To: Dan Wing; 'Reinaldo Penno'; draft-ietf-behave-lsn-
> [email-masked]
> Cc: DENG Xiaohong ESP/PEK; [email-masked]
> > >> port block. But many of those can be mitigated. Having said that,
> I
> > >> would
> Med: Which ones? Dynamic modes have been proposed in A+P; see
> http://tools.ietf.org/html/draft-rqb-dynamic-port-ranges-02. Port
> randomization requirement can be fairly honored.
> 
> Med: This is true for the stateless A+P mode but not the binding mode
> (see: http://tools.ietf.org/html/draft-ymbk-aplusp-09#section-4.4 for
> more details).

Most of the benefits attributed to A+P is that it's stateless in the
SP's network.  I haven't seen anyone excited about that, but I don't
talk to everyone.

-d

> > >>> It is not relevant if they are contiguous or not.  This is a
> false
> > >> sense of
> > >>> security.
> > >>>

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 17:03:44 +0100

=> fine, BTW the description should use 'When the "bin" is empty'
as by convention a port is 'removed' from the "bin" before being
used.

Some extra comments:
 - it can be very good for the security (per flow port randomization)
 - it was I implemented in the ISC AFTR (following a customer request)
 - it is by design not really compatible with EIM (not a surprise:
  port randomization and EIM follow opposite goals). Of course the
  key point is the meaning of 'new outgoing connection'.

Thanks

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 12:34:19 -0700

> Sent: Wednesday, March 16, 2011 7:38 AM
> To: [email-masked]
> Cc: 'behave' <([email-masked])>; draft-ietf-behave-lsn-
> [email-masked]; Benson Schliesser
> * when all the ports in the port set are in-use, a new random port set
> is generated by the CGN, etc until reaching a quota.
> 

I described a continuum from completely random to completely fixed at:
  http://www.ietf.org/mail-archive/web/behave/current/msg09182.html

which said:

   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.

Perhaps that is a good starting point.  Or perhaps this is better:

   1.  for a new outgoing flow, choose a random port and create a new
       mapping.  There is a limit on the maximum number of ports.

   2.  for a new outgoing flow, choose several random ports and create a
       "bin" of those ports.  This outgoing flow is assigned one of
       those ports.  Subsequent outgoing flows will be assigned a port
       from the "bin".  When the "bin" is full, a new flow causes this
       process to be repeated (i.e., a new bin is 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.

   4.  Same as (3), but only one "bin" is allocated.

-d

> Cc : Benson Schliesser; draft-ietf-behave-lsn-
> [email-masked]; 'behave' <([email-masked])>

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 08:09:37 +0100

Dear Simon,

Port can be released when not used anymore. 

Don't see an issue there.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : mercredi 16 mars 2011 15:20
À : [email-masked]
Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment

Simon

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 08:14:10 +0100

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 16 mars 2011 16:06
À : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Reinaldo Penno'; [email-masked]
Cc : DENG Xiaohong ESP/PEK; [email-masked]
Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment

SP's network. 

Med: The binding mode adds only one (few) per-subscriber state compared to a per-session state for the NAT. 

 I haven't seen anyone excited about that, but I don't
talk to everyone.

Med: You should ;-). The binding mode is similar to the DS-Lite but with AFTR=PRR (Port Range Router).

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 08:24:51 +0100

Re-,

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 16 mars 2011 20:34
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : [email-masked]; [email-masked]; 'Benson Schliesser'
Objet : RE: [BEHAVE] CGN REQ: Port Set Assignment

which said:

Med: I don't know where to put the non-contiguous one single "bin" case (excerpt from (see http://tools.ietf.org/html/draft-bajko-pripaddrassign-02#section-4.1)

   "a non Continuous Port Range is assigned to a given customer's
   device. In this example, the Port Range Value defines 128 Continuous
   Port Ranges, each one with a length of 16 port values.  Note that
   the two first Port Ranges are both in the well-known ports span
   (i.e. 0-1023) but these two ranges are not adjacent.

   The following Port Range Mask and Port Range Value are conveyed in
   DHCP messages:
        - Port Range Value : 0000000001010000 (80)
        - Port Range Mask : 0000000111110000 (496)

   This means that the 128 following Continuous Port Ranges are
   assigned to the same device:
        - from 80 to 95
        - from 592 to 607
        - ...
        - from 65104 to 65119"

---

From: <[email-masked]>
Date: Thu, 17 Mar 2011 15:12:27 +0100

Dear Simon,

Not sure I agree.

FYI, based on the experiments done by Xiaohong (e.g., using the tool available at https://www.dns-oarc.net/oarc/services/dnsentropy) on three scenarios which apply also for the CGN context:

* Scenario A: DNS resolver behind a NAT implementing RFC6056
* Scenario B: DNS resolver behind a NAT implementing an algorithm called "A+P simple port randomization algorithm"
* Scenario C: DNS resolver behind an port-restricted NAT implementing "port increment by 1" algorithm

Both Scenario A and B have the same score: "GREAT". Scenario C has a score of "POOR".

More port samplings have been tested and Scenario A and B had almost the same randomness performance.

This is something that can be documented if the community is interested in.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : mercredi 16 mars 2011 15:22
À : [email-masked]
Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Mar 2011 11:06:29 -0700

We need some common terminology.  Invent something.  

-d

> Sent: Thursday, March 17, 2011 12:25 AM
> To: Dan Wing; [email-masked]
> Cc: [email-masked]; [email-masked];
> 'Benson Schliesser'
> Subject: RE: [BEHAVE] CGN REQ: Port Set Assignment
> 
> Re-,
> 
> 
> 
> Cc : [email-masked]; draft-ietf-behave-lsn-
> [email-masked]; 'Benson Schliesser'
> Med: I don't know where to put the non-contiguous one single "bin" case
> (excerpt from (see http://tools.ietf.org/html/draft-bajko-
> pripaddrassign-02#section-4.1)
>

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 17 Mar 2011 16:44:27 -0500

It doesn't matter what kind of port-set you implement - there are no cases
where the port-set feature is a requirement.

There are cases where it is desirable, including logging reduction etc.
Operators that desire this feature should include it in their RFI.  But it
doesn't belong as a MUST or SHOULD in the requirements draft - it ought to
be listed as a MAY item.

Cheers,
-Benson

On 3/16/11 1:16 AM, "[email-masked]"
<[email-masked]> wrote:

> Dear Benson,
> 
> The port set does not means contiguous port range. Random port set can be
> handled by the CGN. This should be explicit in the requirements IMO.
> 
> In deployments where a small address sharing ration is needed (e.g., 1:2,
> 1:3), port randomization is still possible within the large port range.
> 
> À : BOUCADAIR Mohamed OLNC/NAD/TIP;
> [email-masked]

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 17 Mar 2011 16:49:19 -0500

> where the port-set feature is a requirement.

Sorry, I should have said: the port-set feature is not a requirement for
CGN.  There are specific implementations of CGN where it might be inherent
and/or desired, but that doesn't mean it applies to the general case.

Cheers,
-Benson

---

From: <[email-masked]>
Date: Mon, 21 Mar 2011 13:39:38 +0800

For more information, the experiments Med mentioned here is carried out with an address sharing ration (1:64)
And over 2000 ports have been sampled, which shows no significant difference of port randomization  betwwen 
"a NAT implementing RFC6056: Algorithm 1" and "a NAT implementing A+P simple port randomization algorithm".

Cheers,
Xiaohong

|-----邮件原件-----
|发件人: BOUCADAIR Mohamed OLNC/NAD/TIP 
|[mailto:[email-masked]] 
|发送时间: 2011年3月17日 22:12
|收件人: Simon Perreault; [email-masked]; DENG Xiaohong ESP/PEK
|主题: RE: [BEHAVE] CGN REQ: Port Set Assignment
|
|Dear Simon,
|
|Not sure I agree.
|
|FYI, based on the experiments done by Xiaohong (e.g., using 
|the tool available at 
|https://www.dns-oarc.net/oarc/services/dnsentropy) on three 
|scenarios which apply also for the CGN context:
|
|* Scenario A: DNS resolver behind a NAT implementing RFC6056
|* Scenario B: DNS resolver behind a NAT implementing an 
|algorithm called "A+P simple port randomization algorithm"
|* Scenario C: DNS resolver behind an port-restricted NAT 
|implementing "port increment by 1" algorithm
|
|Both Scenario A and B have the same score: "GREAT". Scenario C 
|has a score of "POOR".
|
|More port samplings have been tested and Scenario A and B had 
|almost the same randomness performance.
|
|This is something that can be documented if the community is 
|interested in.
|
|Cheers,
|Med
|
|-----Message d'origine-----
|De : [email-masked] [mailto:[email-masked]] 
|De la part de Simon Perreault Envoyé : mercredi 16 mars 2011 
|15:22 À : [email-masked] Objet : Re: [BEHAVE] CGN REQ: Port 
|Set Assignment
|
|On 2011-03-16 02:16, [email-masked] wrote:
|> The port set does not means contiguous port range. Random 
|port set can be handled by the CGN. This should be explicit in 
|the requirements IMO.
|> 
|> In deployments where a small address sharing ration is 
|needed (e.g., 1:2, 1:3), port randomization is still possible 
|within the large port range.
|> 
|> The I-D already discusses the trade-offs:
|> 
|>    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].
|>       Mechanism (3) provides poor security to subscribers, 
|especially if
|>       the "bin" size is small.
|
|I think it will need to be changed in light of the attack 
|described by Dan. To me, (2) does not appear to be as secure 
|as (1) anymore.
|
|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: Simon Perreault <[email-masked]>
Date: Fri, 25 Mar 2011 20:03:28 -0400

>    (i.e. 0-1023) but these two ranges are not adjacent.

It looks to me like it would be between 2 and 3: somewhat random, but not
completely.

Now, I don't think we need to list all possibilities in the draft. Anyone could
invent a dozen new ones by blending what's already there in varying proportions,
without even trying hard to be creative.

What the text needs to make clear is that this is a continuum, and how the pros
and cons vary as you move along it (as a first step). The next revision will
contain terminology that will work better than numbers for discussion.

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: <[email-masked]>
Date: Sun, 27 Mar 2011 14:05:54 +0200

Dear Benson,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Benson Schliesser [mailto:[email-masked]] 
Envoyé : jeudi 17 mars 2011 22:49
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : 'behave' <([email-masked])>
Objet : Re: [BEHAVE] CGN REQ: Port Set Assignment

Med: If we adopt that perspective, we can also say: 
"the one-by-one mapping feature is not a requirement for
CGN.  There are specific implementations of CGN where it might be inherent
and/or desired, but that doesn't mean it applies to the general case. ", No?

Unlike traditional NATs, the CGN comes with its own design choices and IMO port set is one of them. 

Cheers,
-Benson

---

From: Benson Schliesser <[email-masked]>
Date: Sun, 27 Mar 2011 07:18:33 -0500

Med -

Parsing your inline comment is difficult.  But from what I can tell, I agree
with your straw-man statement: the method for allocating ports is an
implementation issue, and we shouldn't require any one specific approach
(one-by-one, port-set, etc).

It's a good idea to discuss the trade-offs: port allocation method versus
logging, scale, security, etc.  But it goes too far to make a requirement
based on your implementation preference.

Cheers,
-Benson