Subject: Re: [Softwires] The port mapping issue

From: Dan Wing <[email-masked]>
Date: Mon, 1 Apr 2013 11:43:27 -0700

On Mar 27, 2013, at 8:59 AM, Tom Taylor <[email-masked]> wrote:

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

-d

> 
> The reason that I heard given for preferring GMA for MAP-E is that it eliminates a restriction on the End-User Ipv6 address because the PSID is free to range from 0 upwards rather than from some higher number upwards. I don't follow this argument for two reasons:
> 
> - you now have a restriction that the offset field A must range from 1 upwards
> 
> - the PSID field has an upper limit 2^k-1 imposed by the sharing ratio, imposing a further restriction on the End-User IPv6 address value.
> 
> Could someone spell out more clearly why the GMA was seen as necessary for MAP-E?
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Dan Wing <[email-masked]>
Date: Mon, 1 Apr 2013 16:56:08 -0700

On Apr 1, 2013, at 3:17 PM, Ole Troan (otroan) <[email-masked]> wrote:

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

-d

> Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 2 Apr 2013 10:18:15 +0900

Dan,

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

Cheers,
Ole

---

From: Dan Wing <[email-masked]>
Date: Mon, 1 Apr 2013 18:32:39 -0700

> 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