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

["Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[e-mail]>]

>-----Original Message-----
>From: Fernando Gont [mailto:[e-mail]]
>Sent: Wednesday, March 03, 2010 7:56 PM
>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>
> ...
>
>I have no problem with numbering each requirement.
>
>That said, what naming scheme are you thinking of? Flat, or what?
>


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.
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 :).

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.


>> Regarding the requirement:
>> """
>>    If a segment is received with port 0 as
>>    the Source Port or the Destination Port, a RST segment SHOULD be
>sent
>>    in response (provided that the incomming segment does not have the
>>    RST flag set).
>> """
>> The rationale indicates that this is to mitigate against OS
>> fingerprinting,
>
>Actually, it's almost impossible to use port 0 reliably (many
>middle-boxes already filter it, and many end-hosts do not allow its
>use). So *that* is the reason for not using it.
>
>> but no discussion motivates this particular response
>> rather than other alternatives e.g. simply ignoring the segment,
>sending
>> an ICMP port-unreachable, etc.  If there is a specific reason that
>this
>> response is the one chosen to make all implementations look the same
>to
>> 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.


>
>
>> 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.  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.

--
Wes Eddy
MTI Systems