Re: [tcpm] Feedback request on draft-ietf-tcpm-tcp-security

[Fernando Gont <[e-mail]>]

Hi, Wes,

> It doesn't really matter to my; my only concern was
> that they each have a unique identifier to reference
> against more easily than using the full sentence.

That makes perfect sense.


> In order to not cause massive renumberings when
> adding or removing, one system would be to name them
> something like "R.0302001" for the first requirement
> in section 3.2 and "R.1100012" for the twelfth one in
> section 11 (with no subsections).  There may be a
> more elegant way, I don't really care what the ID
> looks like as long as there is one :).

Ok, I'll use your proposal... unless somebody can quickly come up with
something that is clearly better (I can't).

FWIW, the behave folks use "REQ-n"... however, their documents usually
have no more than a dozen requirements... and thus such a "flat" naming
scheme is managable. In our case, we'll probably end-up with more than a
hundred requirements, so such a "flat" scheme would not work that well
here. A more hierarchical one such as the one you describe would work
better.



> If it's too much trouble or nobody else in the WG
> cares, I don't think it's absolutely necessary, I
> just would find it really helpful in my work.

It's not too much trouble (I can add the "numbers" in an incremental
way... as I edit the I-D)... and it is clearly useful. So I will be
adding the req-numbers in the next rev.

(Worst case, if people don't like it, we could eventually remove the
numbers (I guess the only argument against it is that things like
"R.XXXXXX" look like cryptic, but that's it :-) )).



>>> a fingerprinting attempt, then we need to explain that,
>> Agreed. The rationale for that response was "responsiveness" -- i.e.,
>> rather than letting the connection-establishment time-out, you send an
>> RST.
>>
>> But please let me give this one another thought....
> 
> I agree that the port can't and shouldn't be used,
> but if we're starting with the assumption that it's
> never legitimately used, then why would we worry
> about making a timely response to incoming packets
> on that port? I think it's easier to just ignore
> them.  It's like sending responses to spam otherwise.

Makes sense to me.

(I guess at the time I decided that an RST might make sense as it would
signal a "hard error" condition... but in retrospective, I agree with
what you say. For instance, some systems already do this (ignore TCP
segments that use port 0)).



>>> Regarding the requirement:
>>> """
>>>    Middle-boxes such as packet filters MUST NOT assume that clients
>> use
>>>    port numbers from only the Dynamic or Registered port ranges.
>>> """
>>> It's not clear to me how this improves security.
>> Disclaimer: I must say I wasn't sure about including this one as a
>> "requirement" (as this req does not aim at end-systems).
>>
>> That said, while this does not improve the security of end-systems, it
>> provides advice on how to set policies correctly, so that communication
>> is not blocked mistakenly. (i.e., a middle-box must not assume that
>> clients only use port numbers in that range as the source port).
> 
> Ok; but implementing this requirement doesn't at all
> improve the security of TCP implementations, so I
> believe it's out of scope.  

Yes, I agree. As I said before, I wasn't sure whether to include it as a
req. But did so so that we'd discuss it.



> It seems like something
> that would be included in BEHAVE's work (and maybe
> it already is?), but I've not been active in that
> so I could be wrong.

And maybe not even behave... this has more to do with firewalls...

Thanks!

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