On Apr 1, 2013, at 6:18 PM, Ole Troan <[email protected]> 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
