Subject: [shara] port randomization (draft-ymbk-aplusp-03)

From: "Dan Wing" <[email-masked]>
Date: Wed, 11 Mar 2009 17:46:17 -0700

http://tools.ietf.org/html/draft-ymbk-aplusp-03#section-4.8 says, in part:

   ...
   Port randomization is also a bit compromised in A+P solution.  As CPE
   can randomize ports only within port range that is allocated to it,
   randomness is more limited than in the the scenario with full range
   of ports, allowed for randomization.  We can assume, that CPE either
   gets port range from ephemeral range (49152-65535) or from
   "registered ports" range (1024-49151).  Both ranges can be used for
   randomization, see [I-D.ietf-tsvwg-port-randomization] for more
   details.

Has consideration been given to having the PRR return only *one* port
for each request, or to returning a list of port numbers which are
not consecutive and are not a bit-pattern of ports?  These techniques
would allow the PRR to distribute the requests randomly across the 
entire port range instead of within a block of ~100 (or whatever). 

Further fleshing out of the technique described in Section 4.4
("Dynamic allocation of port ranges") could be useful towards 
allowing applications to benefit from the security advantage of 
port randomization.

-d

---

From: <[email-masked]>
Date: Thu, 12 Mar 2009 06:51:32 +0100

>-----Original Message-----
  >From: [email-masked] [mailto:[email-masked]] On Behalf Of
  >ext Dan Wing
  >Sent: Wednesday, March 11, 2009 5:46 PM
  >To: [email-masked]
  >Subject: [shara] port randomization (draft-ymbk-aplusp-03)
  >

This is exactly the intention of section 4 and 5 in http://www.ietf.org/internet-drafts/draft-bajko-pripaddrassign-01.txt

What section 5 describes is a way to communicate a list of preallocated random ports to the client, in an indirect way.

  >allowing applications to benefit from the security advantage of
  
Yes, this is explicitely stated in section 2 of the above mentioned draft.

- gabor

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

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 12 Mar 2009 08:31:18 -0700

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, March 11, 2009 10:52 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [shara] port randomization (draft-ymbk-aplusp-03)
> 
> 
> 
>   >From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
>   >ext Dan Wing
> This is exactly the intention of section 4 and 5 in 
> http://www.ietf.org/internet-drafts/draft-bajko-pripaddrassign-01.txt
> 
> What section 5 describes is a way to communicate a list of 
> preallocated random ports to the client, in an indirect way.

Yes, but that list of random ports would not change until the user
said "I don't want this IP address anymore", perhaps.  What I am
suggesting is that the CPE could say "I don't want this port
anymore" and the CPE could exchange that port for a new random
port.

-d

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Mar 2009 09:17:31 -0700

would a potential implementor care to speak to any resource and scaling
aspects of non-contiguous port assignment?

randy

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Thu, 12 Mar 2009 15:30:35 +0100

> entire port range instead of within a block of ~100 (or whatever). 
Hi. My concern with this approach is massive number of "states" or 
"redirects" in form
"IP+port -> tunnelX", that PRR would have to maintain. On the other 
hand, fragmented blocks of
ports (or one port per request) are much easier to release, when not in 
use anymore. But if we distribute
consecutive blocks to CPE's I think that we considerably lower the 
number of moving parts in the whole system.

Needs to be discussed.
> allowing applications to benefit from the security advantage of 
How important is port randomization and how big is the impact in real 
life, if we randomize within
smaller range? Is it worthy to make already complex solution (shared IP) 
even more complex just because of that?

Regards, Jan Zorz

---

From: <[email-masked]>
Date: Thu, 12 Mar 2009 17:55:36 +0100

Depends on technique chosen for realizing non-contiguous port range. Let's look at the draft-bajko-pripaddrassign's crypto algorithm in DHCP scenario.

These reflect my current understanding.

DHCP server allocating crypto-addresses:
- needs to generate random key per public IPv4 address 
- needs to manage parameters given to each client, but does not need to calculate what ports actually are allocated (just keeps track of 'starting point' and 'number of delegated ports')
- needs to manage lease times per port set instead of per address
=>I don't think DHCP server really has resource or scaling problems 

DHCP client using crypto-addresses:
- The draft-bajko-pripaddrassign's crypto algorithm requires 3 AES-128 bit calls per allocated port, e.g. for 2048 allocated port numbers ~6000 calls are required for AES, which should be similar as encrypting 96 kilobytes of data. Not a concern for devices that able to use e.g. HTTPS for web browsing. Client can do this calculation on-demand when new source port is needed (in which case in bind-phase only 3 AES calls are needed), or in one-time run at the moment of receiving port restricted address from DHCP server.
- A node may need to implement NAT to show private IPv4 addresses on internal side. This is nothing unusual - various devices and CPEs implement NATs already (even some mobile phones have NATs).

Multiplexing gateway:
- The gateway that multiplexes traffic by the port has to calculate these ports as well. For all ports of an IPv4 address this equals encryption of ~3MB (3*64000*128bits)
- The gateway has two options:
1) have precalculated mapping table for each port<->client (e.g. point-to-point link), which is very similar to what NATs have. But as the ports are pre-calculated, the gateway has to have the mappings in memory even if not in use (to allow unsolicited inbound traffic). The memory consumption is probably bigger issue than CPU here. I don't know exactly how much memory one mapping takes (guessing that 16bits of port, and what - 32bits per point-to-point link identifier + some control data would equal ~6 bytes per mapping -> ~375kB per IP address?).
2) calculate ports on fly = when client sends packet, verify that the source port is in allowed range (3 aes calls I think also in this direction), and when (unsolicited) packet is received and no mapping exist yet in memory, find out the correct client based on the observed destination port (3 aes calls I think) - and this calculation is done only for first IP packet of a flow passing trough.

Now if the non-contiguous port set is less random, say contains multiple non-contiguous ranges allocated with port masks (see the same draft), less effort is needed in dhcp-client (no AES calls needed) and multiplexing gateway, as no AES calls are needed and mapping tables can be simpler (as bitmasks can be used). In DHCP server effort is pretty similar except for key generation part that is not needed.

Comments? This is interesting topic to look into.

I don't think these are issues for the end-nodes, but maybe someone who would be involved in gateway implementation could comment their perspectives?

Best regards,

	Teemu

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Randy Bush
>Sent: 12 March, 2009 18:18
>To: [email-masked]
>Subject: Re: [shara] port randomization (draft-ymbk-aplusp-03)
>
>would a potential implementor care to speak to any resource 
>and scaling aspects of non-contiguous port assignment?
>
>randy

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 12 Mar 2009 10:34:45 -0700

> life,

Over the last 10 years there have been several attacks against
TCP and DNS that have exploited predictable emphemeral ports.  The
industry response to those attacks has been to (a) randomize 
ephemeral port selection (rather than incrementing to the next 
port number) and (b) increase the ephemeral port range used by 
the OS.

See
http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization-02#section-1
for more detailed answer to your question.

-d

> if we randomize within

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Thu, 12 Mar 2009 21:48:43 +0100

> for more detailed answer to your question.
Dan, hi.

I'm well aware of that draft, it is also referenced in in A+P draft. 
Maybe I was not clear enough in my question, let me re-phrase it.
In shared IP solutions we are taking away ports from customers, we are 
taking away resources and everything is a compromise.
Being said that, if we are happy with compromise, why not introduce 
compromise also in a dirty hack as port randomization is.
 So, can we live with randomization within for example range of 512 
ports? Is this "good enough"? We are quite fond of accepting
the compromise of shared IP as "good enough", because we have no other 
option, so can we accept also the compromise of less randomness in
port randomization hack?

I'm also curious to hear some aproximation from any HW vendor, what does 
allocating "one port per request" means for PRR in larger scale. I 
suspect this
might very well be performance suicide, but this is only my speculation. 
If not - good, we can go in that direction, which I recognise as good 
also in several other ways.

Thank you for your time and effort, Jan Zorz

---

From: <[email-masked]>
Date: Fri, 13 Mar 2009 09:08:28 +0100

This is a good question.
I'm also wondering, currently how many OSs and how many NATs do implement a good randomization function?
 
More generally, in port range solutions we (I include myself) propose sophisticated functions that surely make sense.
However, I do believe that, if we want to see vendors rapidly implement port range capabilities, we have to agree on a minimum set of functionalities that makes it possible to build a viable port range solution.
I'm very convinced, for example, that it is straighforward (I mean almost no cost and without any performance lost) for all vendors to upgrade their routers to PRRs (Port Range Router), we did that on Linux only by configuration.

Pierre

________________________________

De : [email-masked] [mailto:[email-masked]] De la part de Jan Zorz @ go6.si
Envoyé : jeudi 12 mars 2009 21:49
À : [email-masked]
Objet : Re: [shara] port randomization (draft-ymbk-aplusp-03)

Dan Wing wrote: 

	
	
	See

Dan, hi. 

I'm well aware of that draft, it is also referenced in in A+P draft. Maybe I was not clear enough in my question, let me re-phrase it.
In shared IP solutions we are taking away ports from customers, we are taking away resources and everything is a compromise. 
Being said that, if we are happy with compromise, why not introduce compromise also in a dirty hack as port randomization is.
 So, can we live with randomization within for example range of 512 ports? Is this "good enough"? We are quite fond of accepting 
the compromise of shared IP as "good enough", because we have no other option, so can we accept also the compromise of less randomness in 
port randomization hack? 

I'm also curious to hear some aproximation from any HW vendor, what does allocating "one port per request" means for PRR in larger scale. I suspect this 
might very well be performance suicide, but this is only my speculation. If not - good, we can go in that direction, which I recognise as good also in several other ways.

---

From: Lars Eggert <[email-masked]>
Date: Fri, 13 Mar 2009 10:22:45 +0200

> implement a good randomization function?

No need to wonder, at least for OS: http://tools.ietf.org/html/draft-ietf-tsvwg-port-randomization-02#appendix-A

Lars

> More generally, in port range solutions we (I include myself)  
> propose sophisticated functions that surely make sense.
> However, I do believe that, if we want to see vendors rapidly  
> implement port range capabilities, we have to agree on a minimum set  
> of functionalities that makes it possible to build a viable port  
> range solution.
> I'm very convinced, for example, that it is straighforward (I mean  
> almost no cost and without any performance lost) for all vendors to  
> upgrade their routers to PRRs (Port Range Router), we did that on  
> Linux only by configuration.
>
>
>
> Pierre
>
> In shared IP solutions we are taking away ports from customers, we  
> are taking away resources and everything is a compromise.
> the compromise of shared IP as "good enough", because we have no  
> other option, so can we accept also the compromise of less  
> randomness in
> port randomization hack?
>
> I'm also curious to hear some aproximation from any HW vendor, what  
> does allocating "one port per request" means for PRR in larger  
> scale. I suspect this
> might very well be performance suicide, but this is only my  
> speculation. If not - good, we can go in that direction, which I  
> recognise as good also in several other ways.
>
> <ATT00001.txt>

---

From: "Rémi Denis-Courmont" <[email-masked]>
Date: Fri, 13 Mar 2009 10:23:13 +0200

Hello,

> How important is port randomization and how big is the impact in real

It depends a _lot_ on the protocol.

To reiterate what Dan said, DNS is vulnerable. The well-publicized attacks on 
DNS (and in particular the "Kaminsky" vulnerability) rely on predictable port 
numbers. Or rather, they are mitigated by port randomization.

In principle, running a DNS cache on the NAT/address-sharing box could solve 
this. DNS would be proxied at the application layer, and so port randomization 
could be achieved properly by the box. Unfortunately, some of "box" vendors 
probably do not want to have to provide a DNS cache.

-- 
Rémi Denis-Courmont
Centralien
Nokia Devices R&D, Maemo Software, Helsinki

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sat, 14 Mar 2009 08:45:51 +0100

Pierre, hi.

> This is a good question.
Thnx. Let's wait for an answer to pop up (if) :)
> implement a good randomization function?
Not sure... but rather than port randomization I would prefer to see 
dnssec implemented in clients, maybe also combined with dnscurve.
>  
> More generally, in port range solutions we (I include myself) propose 
> sophisticated functions that surely make sense.
We have no other option. But, how sophisticated (complex) may we get? 
Where is the balance between "good enough" usability and complexity on 
the other hand?
> of functionalities that makes it possible to build a viable port range 
> solution.
If we want to assure at least minimum compatibility between different 
vendors equipment and still have a solution, that makes sense to 
customer, then we need to set, what minimum means. I suspect every 
vendor will speculate with it's own proprietary features, so we need to 
set basics straight. You are perfectly right.
> Linux only by configuration.
Did you implement non-contiguous port allocations?

regards, Jan Zorz
>  
>  
>  
> Pierre
>
> ------------------------------------------------------------------------
> *De :* [email-masked] [mailto:[email-masked]] *De la 
> part de* Jan Zorz @ go6.si
> *Envoyé :* jeudi 12 mars 2009 21:49
> *À :* [email-masked]
> *Objet :* Re: [shara] port randomization (draft-ymbk-aplusp-03)
>
>
>
> Dan Wing wrote:
> does allocating "one port per request" means for PRR in larger scale. 
> I suspect this

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sat, 14 Mar 2009 08:55:09 +0100

> probably do not want to have to provide a DNS cache.
Remi, hi.

This seems quite a good idea. Maybe we should think and search for a 
solution in this direction.
Why do you suspect, that some of the vendors would refuse to provide a 
DNS cache?

regards, Jan Zorz

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sat, 14 Mar 2009 09:04:44 +0100

Teemu, hi.
> Now if the non-contiguous port set is less random, say contains multiple non-contiguous ranges allocated with port masks (see the same draft), less effort is needed in dhcp-client (no AES calls nee…
Exactly.
> I don't think these are issues for the end-nodes, but maybe someone who would be involved in gateway implementation could comment their perspectives?
ISP's already have issues with not enough memory in CPE for firmwares 
even without v6 and/or shared IP solution. With growing complexity of 
shared IP solution their problem is not going away, but getting bigger 
:) If we suspect, that ISP will replace all the HW, then we can go 
complex. If we suspect, that ISP will want to "just upgrade" CPE 
firmware to support IPv6 and shared IP, then we need to do something 
that would fit into HW of yesterday and today. Am I somehow thinking 
into sensible direction?

regards, Jan Zorz

---

From: Rémi Després <[email-masked]>
Date: Sat, 14 Mar 2009 11:32:39 +0100

> dnssec implemented in clients, maybe also combined with dnscurve.
DNSsec is better, but hosts have to also support DNS servers that don't 
have, and therefore port randomization.
Note that, if both hosts and DNS have IPv6 addresse, hosts are can 
randomize on the full range of ephemeral ports (not concerned with Shara 
mechanisms).

> Where is the balance between "good enough" usability and complexity on 
Full agreement.
The proposal than is included in SAM 
(www.nabble.com/FYI:-draft-despres-sam-02--enclosed-td22493319.html) is 
intended to be good enough and simpler than the other proposals so far.
(Routing is still based on prefixes, and the cyphering function is just 
a modulo 2^n multiplication by an odd constant of the bits to be scrambled.)
> vendor will speculate with it's own proprietary features, so we need 
> to set basics straight. You are perfectly right.
Full agreement.

Regards,

RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 14 Mar 2009 12:02:25 +0100

> What section 5 describes is a way to communicate a list of preallocated random ports to the client, in an indirect way.
draft-bajko-pripaddrassign seems to me an excellent document to start with.

In www.nabble.com/FYI:-draft-despres-sam-02--enclosed-td22493319.html, I 
propose another method to avoid using consecutive port numbers on the 
global Internet.

If agreeable, I could propose a new section to deal with it in 
draft-bajko-pripaddrassign.

Parameters to be advertised in what could be sub-option 3, would be:
- the IPv4 address
- the dynamic port prefix
- the scrambling multiplier (e.g. 32 bits)
- the number of high order bits of the IPv4 address that must not be 
scrambled
 
This new sub-option is expected to be simpler than sub-options 1 and 2, 
and good enough.

In some respect it is also more powerful because it can  randomize not 
only port bits but also some lower bits of the IPv4 address: those that 
are after the IPv4 prefix of the multiplexing gateway (aka the PRR).

I look forward to discussing all this in SF.

Regards,

RD

---

From: <[email-masked]>
Date: Sat, 14 Mar 2009 12:32:05 +0100

Hi Jan,

There is indeed need for trade-off discussions at some point, and to also look whether different deployment scenarios are happy with something other deployment scenarios are not. E.g. it may make a difference whether a host is allocated 1,10,10,1000, or 10000 ports.

I do not believe ROM requirements in CPEs or hosts can be a real factor here - the code changes required for port restricted addresses are small (there's no new protocol, just new parameters on the existing ones + control SW - especially if indeed can be handled just by configuration on some platforms). I also don't think there's any mandatory requirement to upgrade existing CPEs or hosts - those are already addressable. The port restricted address support can be deployed along with new devices (perhaps at the same time those are added with IPv6 support?).

While AES support may be an issue for CPEs - I don't know what features CPEs currently have - it is not an issue say e.g. for cellular devices, which already have all the crypto libraries required for SSL/TLS and often also for IPsec.

If a device is so restricted that it cannot do port restricted addressing, then its best to move to IPv6 or obtain enough full IPv4 addresses from somewhere.

Best regards,

    Teeu

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Jan Zorz @ go6.si
Sent: 14 March, 2009 10:05
To: [email-masked]
Subject: Re: [shara] port randomization (draft-ymbk-aplusp-03)

Teemu, hi.

Exactly.

ISP's already have issues with not enough memory in CPE for firmwares even without v6 and/or shared IP solution. With growing complexity of shared IP solution their problem is not going away, but getting bigger :) If we suspect, that ISP will replace all the HW, then we can go complex. If we suspect, that ISP will want to "just upgrade" CPE firmware to support IPv6 and shared IP, then we need to do something that would fit into HW of yesterday and today. Am I somehow thinking into sensible direction?

---

From: "MILES DAVID" <[email-masked]>
Date: Sun, 15 Mar 2009 12:01:06 +0800

>I'm also curious to hear some aproximation from any HW vendor, what
does allocating "one port per request" means for PRR in larger scale. I
suspect this 

My concern with "one port per request" is not so much the port
assignment (we are doing high volumes/rates for), but the high
transaction rate of the messaging protocol. Both
draft-bajko-v6ops-port-restricted-ipaddr-assign and
draft-boucadair-dhc-port-range propose DHCP for this CPE-to-PRR. If we
want to support 128k A+P CPE on a single DHCP server (be this the BRAS
itself or a central server) this would generate a high number of DHCP
transactions/second if a single port is returned per request. There is
also going to be some delay associated with the messaging protocol that
may require a different buffering approach in the CPE until an eternal
port is returned.
A "one port per request" approach also suggests the DHCP server is now
making the decision on what outside port you would be given -
consideration would need to be given to methods allowing CPE to request
specific ports not unlike NAT-PMP or UPnP does today. 

Dan Wing:
>not consecutive and are not a bit-pattern of ports?

Having a well-defined per-subscriber port-range has other benefits for
functions like customer identification (source ip+source port). I'm sure
we have all been involved in cases where either law-enforcement or
another operator/content provider has sought to advise an ISP of a
problem customer by providing IP and timestamp. If we returned a random
list of ports these would need to be stored. 

I agree with Jan's suggestion of port randomization within a port-range.
It would be good to see this in CGN as well.

Regards,

-David

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Sun, 15 Mar 2009 21:39:11 +0100

> It would be good to see this in CGN as well.
Appreciate.

Thnx, /jan

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Mar 2009 08:15:15 -0700

> On Behalf Of Jan Zorz @ go6.si
> Sent: Thursday, March 12, 2009 1:49 PM
> To: [email-masked]
> I'm well aware of that draft, it is also referenced in in A+P 
> draft. Maybe I was not clear enough in my question, let me 
> re-phrase it.
> In shared IP solutions we are taking away ports from 
> customers, we are taking away resources and everything is a 
> compromise. 
> Being said that, if we are happy with compromise, why not 
> introduce compromise also in a dirty hack as port randomization is.
>  So, can we live with randomization within for example range 
> of 512 ports? Is this "good enough"? We are quite fond of accepting 
> the compromise of shared IP as "good enough", because we have 
> no other option, so can we accept also the compromise of less 
> randomness in 
> port randomization hack? 
> 
> I'm also curious to hear some aproximation from any HW 
> vendor, what does allocating "one port per request" means for 
> PRR in larger scale.

This is what today's NAPT devices do today, but without a separate
protocol to request each port.

And, the CPE does not necessarily need to request each port; it
could ask for ~5 or ~10 ports and then utilize them as it needs,
and then get another batch of ~10 ports.  It comes down to
the design decisions for the protocol between the CPE and the 
PRR so that it is possible to utilize the entire 64K port 
range.

-d

> speculation. If not - good, we can go in that direction, 
> which I recognise as good also in several other ways.
>

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Mon, 16 Mar 2009 19:48:45 +0100

Dan, hi.
> protocol to request each port.
I meant PRR on a big scale in ISP's access network.
> PRR so that it is possible to utilize the entire 64K port 
Yes, this is possible within described mechanism in A+P proposal, as 
minimum port range is not limited, so you can define 10 ports as a 
range, but preferably a range, that can be described with a bitmask.

Thank you, Jan Zorz

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Mar 2009 17:32:49 -0700

> Yes, this is possible within described mechanism in A+P 
> proposal, as minimum port range is not limited, so you can 
> define 10 ports as a range, but preferably a range, that can 
> be described with a bitmask. 

I agree that allocating ports is discussed in Section 4.4
of http://tools.ietf.org/html/draft-ymbk-aplusp-03; however,
my point is that additional work is necessary to *release*
ports, so that the CPE can get a fresh port (or fresh block
of ports).

-d

---

From: <[email-masked]>
Date: Tue, 17 Mar 2009 02:07:55 +0100

>additional work is necessary to *release*

Isn't this the task of the protocol between the PRR and CPE? Wouldn't a lease time associated with each allocated port or port range be enough?

- gabor

  >Sent: Monday, March 16, 2009 5:33 PM
  >To: 'Jan Zorz @ go6.si'
  >Cc: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Mar 2009 18:23:17 -0700

> Sent: Monday, March 16, 2009 6:08 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Isn't this the task of the protocol between the PRR and CPE? 

Yes.

> Wouldn't a lease time associated with each allocated port or 
> port range be enough?

Somewhat; the CPE might want to get a new port more aggressively
for whatever reason.

Let's pretend we had a SHARA solution in place in 2005, and 
everybody agreed in 2005 that a 1 hour lease made sense.  The
SP equipment was configured to provide a 1 hour lease of a
bunch of random ports.  Then Kaminsky DNS attack surfaces in 2008, 
3 years later.  Due to that attack, CPE want to get a fresh, 
random UDP port for every DNS query.  Does the existing DHCP 
lease mechanism support a CPE wanting/needing to do that?  It
is my understanding that it does not; if my understanding is
correct, I believe it is in our best interest to be have a 
protocol that does support the CPE asking for whatever port
forwarding it wants/needs.  Putting the power into the 
customer's hands rather than the SP's hands is the primary 
goal of SHARA, afterall.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Mar 2009 18:30:07 -0700

Following up on my own post: 

> is my understanding that it does not;

That is, for some ports (read: applications), aggressively
short port leases may be desirable while for other ports it 
may be desirable to have longer leases.  Having the client
request a short lease duration for any port might work, but
seems chatty because the client will have to refresh the
lease even for ports that are actively sending/receiving
traffic.  The PRR can already tell which ports are actively
sending/receiving traffic (because it is forwarding that
traffic).

Perhaps this is getting too much into the details of the
design of the protocol between the CPE and the PRR.

-d

> if my understanding is
> >   >> 	And, the CPE does not necessarily need to 
> request each port;
> >   >it
> >   >> 	could ask for ~5 or ~10 ports and then utilize 
> them as it
> >   >needs,

---

From: <[email-masked]>
Date: Tue, 17 Mar 2009 08:40:52 +0100

The problem of port randomization with port range solutions comes from the fact that when an attacker knows the port range (it he does not know it the problem is somehow different), the smaller the port range is, the more predictable the port choice is.

I would like to re-ask a question previously raised by Jan Zorz:

Do we know how many ports we need to put into a port range to see this effect mitigated?
If a proposed randomization algorithm works well for 50,000 ports, what level of efficiency does it achieve for 10,000 ports?
What is the threshold under which randomization is definitely not properly achieved?

Is there a quantitative response?

Pierre

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jan Zorz @ go6.si
Envoyé : dimanche 15 mars 2009 21:39
À : MILES DAVID
Cc : [email-masked]
Objet : Re: [shara] port randomization (draft-ymbk-aplusp-03)

Appreciate.

Thnx, /jan

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 17 Mar 2009 11:53:09 +0100

Dan, Gabor, hi.
> design of the protocol between the CPE and the PRR.
Pierre joined me with my question, how big allocation of ports is big 
enough for randomisation. Let's try to find out that first.
The other suggestion, that I found quite interesting (if not brilliant) 
is to offload DNS resolving to the core (PRR?) and do port randomisation 
there.

Regards, Jan Zorz

---

From: <[email-masked]>
Date: Tue, 17 Mar 2009 13:58:31 +0100

Dear Jan,
 
What does mean to offload the DNS resolving to the core?
 
Cheers,
Med 

  _____  

De : [email-masked] [mailto:[email-masked]] De la part de Jan Zorz @ go6.si
Envoyé : mardi 17 mars 2009 11:53
À : Dan Wing
Cc : [email-masked]; [email-masked]
Objet : Re: [shara] port randomization (draft-ymbk-aplusp-03)

Pierre joined me with my question, how big allocation of ports is big enough for randomisation. Let's try to find out that first.
The other suggestion, that I found quite interesting (if not brilliant) is to offload DNS resolving to the core (PRR?) and do port randomisation there. 

Regards, Jan Zorz

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 17 Mar 2009 14:14:19 +0100

> What does mean to offload the DNS resolving to the core?
Mohamed, hi.

If I may, I would copy/paste Remi Despres's text from one of the emails 
on this list:

"In principle, running a DNS cache on the NAT/address-sharing box could solve 
this. DNS would be proxied at the application layer, and so port randomization 
could be achieved properly by the box. Unfortunately, some of "box" vendors 
probably do not want to have to provide a DNS cache."

This idea seems to be a fair trade... but it depends on vendors will to 
implement it. Personally I see no reason, why
some vendor would refuse to do it, as it solves and answers to a lot 
more questions than creates.

Thank you, Jan Zorz

---

From: <[email-masked]>
Date: Tue, 17 Mar 2009 14:21:22 +0100

Thanks.
 
What I missed in your initial answer is why you are referring to offloading the DNS resv to the **core (PRR)**.

Cheers,
Med

  _____  

De : Jan Zorz @ go6.si [mailto:[email-masked]] 
Envoyé : mardi 17 mars 2009 14:14
À : BOUCADAIR Mohamed RD-CORE-CAE
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [shara] port randomization (draft-ymbk-aplusp-03)

Dear Jan,

Cheers,
Med 

Mohamed, hi. 

If I may, I would copy/paste Remi Despres's text from one of the emails on this list:

This idea seems to be a fair trade... but it depends on vendors will to implement it. Personally I see no reason, why 
some vendor would refuse to do it, as it solves and answers to a lot more questions than creates.

Thank you, Jan Zorz

---

From: "Jan Zorz @ go6.si" <[email-masked]>
Date: Tue, 17 Mar 2009 14:44:27 +0100

[email-masked] wrote:
>  
> Thanks.
>  
> What I missed in your initial answer is why you are referring to 
> offloading the DNS resv to the **core (PRR)**.
Mohamed, hi.

Sorry for the mess. This referred to avoiding to complicate even further 
with port randomization within contiguous, non-contiguous or random port 
ranges allocated to CPE. My personal feeling is that we already did a 
solution complex enough and we might not have to go towards the way of 
making it even more complex.

Thanks, Jan Zorz

---

From: <[email-masked]>
Date: Tue, 17 Mar 2009 14:58:18 +0100

Thank you for  this clarification. 
 
Please see inline.

  _____  

Envoyé : mardi 17 mars 2009 14:44

Thanks.

Mohamed, hi.

Sorry for the mess. This referred to avoiding to complicate even further with port randomization within contiguous, non-contiguous or random port ranges allocated to CPE. My personal feeling is that we already did a solution complex enough and we might not have to go towards the way of making it even more complex.

[Med]  Randomisation should not be seen as a target per se, but rather the problem it solves. For me, randomisation does not solve security issues but makes difficult some attacks. Non-contiguous port range does also...
 
Randomisation can also be implemented with port range solutions, but some concerns are to be studied: 
- What is the port range limit beyond which randomisation is not **efficient**? 
- If randomisation is to be implemented, instead of non contiguous port ranges for instance, what is the impact on the PRR performances?
 
BTW, I agree with you and Pierre that a minimum of functionalities are needed to have implementation of port range solution. 
 
Cheers,
Med 

Thanks, Jan Zorz