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

[<[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of ext Jan Zorz @ go6.si
Sent: 14 March, 2009 10:05
To: [e-mail]
Subject: Re: [shara] port randomization (draft-ymbk-aplusp-03)

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 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.


Exactly.

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?


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?