Re: [Tsvwg] WGLC for Port Randomization starts now (April 1st)

[Fernando Gont <[e-mail]>]

Hello, Mark,

Comments in-line....


>>>   - Section 2.2: suggest tacking "at a given point in time" to the end
>>>     of the last sentence.
>> I wasn't able to find the aforementioned sentence. :-(
> 
> I am referring to the last sentence in section 2.2.  This could also be
> viewed as the sentence immediately before the start of section 2.3.

Sorry, I wasn't able to do it (probably "english as a second language"
going on here).

The current sentence is:

"  Additionally, if an
   attacker could force a client to periodically establish a new TCP
   connection to an attacker controlled machine (or through an attacker
   observable routing path), the attacker could subtract consecutive
   source port values to obtain the number of outoing TCP connections
   established globally by the target host within that time period (up
   to wrap-around issues and 5-tuple collisions, of course)."



>>>   - I found the notion of a bit array in 3.2 to be way too much detail.
>>>     Just note that a host could introduce a system to track which port
>>>     numbers are going to be used specifically by applications and leave
>>>     it at that.  The bit array isn't the Clear Right Answer so just
>>>     leave the data structures out.
>> IIRC, I had included this note as that how this has already been
>> implemented on some OSes (e.g., OpenBSD). Please let me know if you feel
>> strongly about removing this text.
> 
> Perhaps relegate it to an appendix and note more specifically this is
> what OpenBSD does.  Ultimately, I don't think the document turns on this
> point, but I found it out-of-place.

You are arguing against the inclusion of "array of bits" as an
implementation approach, rather than against that of "keeping a list of
the reserved ports in the range 1024-65535, right? - If so, I will tweak
the text.


> 
>>>   - 3.3.5: I'd like to see more prose about algorithm 5 to mirror the
>>>     other sections.  I.e., to give the intuition behind it, etc.
>> Any proposed text?
> 
> Well, no.  I suppose I could generate some if pressed.  But, it'll take
> me some time to get to it.

Ok. Will craft some text and post it on the list for review.



>>>   - 3.5: You should likely add the caveat to our results that goes "in
>>>     the two environments assessed" or something like that.
>> You mean in the context of "The larger the
>>    value of "N", the more similar this algorithm is to the algorithm
>>    described in Section 3.3.1 of this document.", or where?
> 
> No.  In section 3.5.

Will do. (Sorry, it seems I had misread your comment).




>>>   - And, if I had one request about data it would be to note that no
>>>     matter what algorithm is chosen the fraction of hosts we saw having
>>>     *any* collisions is exceedingly small.  I.e., the collision problem
>>>     is really a non-problem for most cases.  And, so it might be
>>>     reasonable to use something dumb and simple in the general case and
>>>     a little more expensive in a less general case.  At least that's how
>>>     I think the data really comes down.
>> Isn't this already noted in Section 3.5?
> 
> Without going back to re-read right now... No, I don't think so.  It
> would be nice, I think, to say that in the general case collisions are
> way, way rare using any of these algorithms according to the data that
> has been analyzed.

Will do.

P.S.: Please let me know if there are any issues open, so that I start
working on a rev of the port randomization I-D.

Thanks,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1