Tom, > Taking your comment literally, I'd say that the number of blocks is more > relevant than the block size, so maybe the formula shouldn't be there. Just > in case you didn't understand what a block is, I illustrate the ideas below. > > The basic idea is that, instead of assigning a single sequence of ports to a > CE, the port space from whatever to 65535 is divided up into equal-size > chunks, or blocks, and the CE is assigned a sequence of m ports from each > block. I assume that this is done to make a port-guessing attacker's job more > difficult, but I'm not sure it does so if the attacker knows the algorithm. > My own view is that the MAP document could get rid of a bunch of complexity > if, like lw4o6, it left the *port* mapping algorithm to a separate draft. The > PSID could stay, since it is needed, but the only thing important to MAP is > the *address* mapping algorithm.
no, the port mapping algorithm in MAP is _not_ written the way it is to make an attackers job more difficult. the port mapping algorithm in MAP is the simplest algorithm we could think of, that would exclude the well known ports with arbitrary values of PSID. I don't at all see why moving the port mapping algorithm out of the document would make things simpler. it would make it a lot more complex. then you'd end up with having to support many different port algorithms. cheers, Ole > Anyway, here is your illustration. Assume for example that a = 4, implying a > block size of 4096 (0x1000) port numbers. Thus port number space is divided > up into 16 blocks as shown in the figure below. Hex notation is used for > neatness. > > What is also shown below is the set of ports allocated to a particular CE, > represented by P..P. This is a sequence occuring at the same relative > position in every block. The PSID is an index that points to that relative > position. The first port number, in fact, is PSID * m from the beginning of > the block, where m is the total number of ports in the sequence P..P. > > Port > > ---- > 0x0000 > > > Block not used -- contains system ports. > > > > > 0x0FFF > ---- > 0x1000 > > > P..P > > > > > 0X1FFF > ---- > 0x2000 > . > . > . > . > 0xEFFF > ---- > 0xF000 > > > P..P > > > > > > 0xFFFF > ---- > > On 29/01/2013 12:54 AM, Qi Sun wrote: >> >> Dear Tom, >> >> IMHO, these are valuable comments. However, I'm kind of lost on this >> part: >> >>> A Indexes the blocks of port numbers. The lowest block number >>> (A = 0) and possibly others contain the system port numbers, and >>> hence should not be used if port numbers 0-1023 are to be avoided. >>> >>> a Width of the field containing the block index A. Indirectly a >>> determines the block size, by the formula: Block size = 65536 / >>> 2^a >> >> >> I'm not sure of the meaning of 'Block size', which is equal to >> 2^(k+m). As I interpret, each CE can get 2^(a+m) ports and each port >> range is 2^m. What can we use the 'Block size' for? >> >> Thanks in advance! >> >> Best Regards, Qi Sun >> >> >> On 2013-1-29, at 上午12:59, Tom Taylor wrote: >> > ... > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
