Re: [Softwires] The port mapping issue

[Dan Wing <[e-mail]>]

On Apr 1, 2013, at 6:18 PM, Ole Troan <[e-mail]> wrote:

> Dan,
> 
>>> 
>>>>> The meeting minutes record a disagreement over what port mapping algorithm to use. This affects both MAP-E and LW 4over6. As I understand it:
>>>>> 
>>>>> - either of these two technologies will work with either contiguous ports or ports scattered according to the GMA algorithm
>>>>> 
>>>>> - the real objection to GMA comes from Alain Durand, who wants to set up simple min-port, max-port filters on his network equipment.
>>>>> 
>>>>> 
>>>>> We all agree that port scattering offers negligible security advantage.
>>>> 
>>>> Port scattering, using GMA, provides tiny security advantage.  An attacker can determine the Generalized Modulus Algorithm, by causing a victim to open a bunch of TCP connections.  One way an attacker can cause a bunch of TCP connections to be opened is by sending an email with a bunch of <img src> tags to servers where the attacker can observe the TCP source ports for the connections.  Another way is to do the same with a web page.  GMA is a good amount of engineering and confusion for little gain, but the *appearance* of a gain because to a person the port numbers will appear random.  On other words, a false sense of security.  Port numbers are being used in courts of law and explaining GMA to the lay person will be complex.  I believe it is an unnecessary complexity.
>>> 
>>> Can you please read the latest draft?
>>> What exactly is complex and confusing?
>> 
>> Non-contiguous ports are more confusing than contiguous ports, especially to people that don't understand binary math.  IP stacks used to allow non-contiguous 1's in subnet masks which were cute, but caused confusion with the humans.  (and some stacks couldn't cope well, but that is another topic.)  I worry about the humans being confused with the binary math.
>> 
>> 
>>> GMA aka "port prefix" was not designed for scattering ports, that's a side effect. The requirement leading to that effect is, independence of end user ipv6 prefix. I.e avoid having to reserve a specific ipv6 prefix from assignment.
>> 
>> I agree the requirement is something we need.
>> 
>> Appendix B of draft-ietf-softwire-map-05.txt (March 18, I presume 'the latest') mentions the port scattering as an extreme case, which the algorithm supports.  Can we remove that support?
> 
> Arguing over perceived complexity is always going to be subjective. 
> 
> The main text (section 5) was rewritten to give a simpler and hopefully more understandable explanation than appendix B. 
> 
> To reiterate the reasoning:
> 
> Requirements:
> 1. Exclude the system ports
> 2. No dependency on end user ipv6 prefix. 
> 3. Fair distribution of ports among the sharers of the ipv4 address
> 
> The simplest port range representation I can think of is a 'port prefix', which is just like an address prefix. E.g you get a /8 of ports. (256). That representation does not exclude the system ports though. Remi's insight was that if you made it a 'port infix' (right shifted by 6) and require the msb bits to be larger than 0 you achieve all of the requirements above. Why 6? Because 2^(16-6) = 1024. So all sharees of that range excludes any port below 1024 and the ports they 'loose' from the range equal 1024/sharing ratio.
> 
> The side effect of the infix is scattered port ranges. 
> 
> I believe the answer to your question is no. (But I cannot prove that there aren't other representations that do not fulfill the requirements and only do contiguous ports.) 

Thanks for the explanation.  I can live with that.  Explaining the binary math to network operators and to law enforcement will be a challenge.

Carry on,
-d