Below.
On 30/01/2013 5:41 AM, Ole Troan wrote:
Tom,
...
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
My first reaction to that is to say: unless we fix a at 4, you're going
to be stuck with implementing the a = 0 case anyway, so you might as
well use that and exclude the lowest values of PSID if you want to keep
things simple. The WG really needs to have an opinion on which direction
to go here.
Thinking in terms of the broader picture, I still wonder if the port
mapping algorithm should be documented separately with MAP having a
normative dependency on it, just so the algorithm is reusable amongst
all A+P variants.
Tom
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
