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

[<[e-mail]>]

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


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] 
>On Behalf Of ext Randy Bush
>Sent: 12 March, 2009 18:18
>To: [e-mail]
>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
>_______________________________________________
>shara mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/shara
>